Cross-runtime interop

A standard job lives in one Redis hash at emq:{queue}:{jobId} with the same compressed field names in every runtime — including atm (attempts made). The Go port and the Elixir reference write and read that field identically:

// Go — write atm on the hash (queue_impl.go ~102), read it back (script_runner.go ~160)
"atm": job.AttemptsMade
data["atm"]

# Elixir — Job.from_redis/4 reads the same compressed fields: atm/ats/stc/deid/defa/nrjid
EchoMQ.Job.from_redis(raw_fields, queue, prefix, conn)

So a job enqueued by Go and fetched by an Elixir worker — or the reverse — agrees on every field, because the field names are L1 and the transition scripts are L2. The honest seam: Node.js is the BullMQ reference implementation, and EchoMQ has no first-party Node runtime today. v1 interop in practice is Elixir ↔ Go ↔ upstream-BullMQ-Node, all on the shared emq: wire.

The shared wire above is the v1 line (frozen at 1.3.0). emq.1 ships EchoMQ 2.0, which leaves the BullMQ wire deliberately, once, and versioned. Pick a key type to compare the v1 key against what emq.1 ships as its v2 form — the emq: prefix, and the per-queue {q} hashtag the core places transparently. The v2 side is always what emq.1 ships, not shipped code.

Once the wire is EchoMQ's own, interop is the fleet's own too:

• Stock BullMQ clients cannot speak v2 — by design. A v2 deployment never reads or writes emq:*; that is the honest fleet seam.
• emq.1 ships a fleet-interop probe — a job enqueued by one first-party runtime is fetched and completed by another, both directions, the harness runtime-pluggable. Honest status until then: Elixir is the only v2 speaker; the Go port must implement 2.0 to join.
• A first-party echomq-node is proposed — a Node.js runtime with the Dragonfly target and the same transparent {key} convention. It is proposed; it does not exist.

The payoff of every key declared and every queue hashtagged is DragonflyDB-native multithreading. Dragonfly is thread-per-shard: a key's {hashtag} decides its owning thread. With v2, --lock_on_hashtags locks precisely — one queue per thread, distinct queues across cores — and the deployment never needs --default_lua_flags=allow-undeclared-keys, the whole-store escape hatch that v1's undeclared keys would otherwise force. The two flags are the v2 substrate's posture: require --lock_on_hashtags, never set the allow-undeclared-keys flag.

Interop is a property of the wire, not of any one runtime. One job hash, the same field names (atm …, L1), the same transition scripts (L2) — and a job round-trips between any two runtimes that share them. Each runtime reads and writes those keys its own way (L3/L4): Elixir with OTP processes, the Go port with goroutines, and (in v2) the proposed echomq-node with its event loop.

The shared wire and job-hash field set, and the Dragonfly substrate the v2 fork targets.