Cross-comparison — Go vs Node, Postgres-only vs +Redis, outbox vs BullMQ

The comparative round is where ownership shows. Six axes, each with a crisp verdict and the reason.

1. Runtime: Go vs Node. Go: static binary, tiny image, real parallelism, goroutines for loops/consumers, SQLC for explicit SQL, GC pauses irrelevant at this scale. Node: one language across extension/backend/tooling, unbeatable I/O-bound ergonomics, but one stalled callback blocks everything (hence streaming, bounded JSON, worker offload). Verdict: pick by workload shape and ecosystem, not benchmarks — and both were right for their contexts (Day 8).

2. Datastore: Postgres-only vs Postgres+Redis. Zoth: nothing hot, nothing ephemeral → Postgres does state, queueing (outbox), search (pgvector), locks (advisory), scheduling (ticker + claims) → one thing to operate, one consistency model. Traverse: hot cached reads, a job pipeline with delayed/repeatable work, and rate-limit counters → Redis earns its seat, with the discipline that nothing lives only there (DB-first writes). Verdict: components are added for measured needs, not symmetry — and the asymmetry is the point (Day 5).

3. Async: transactional outbox vs BullMQ. Outbox: atomicity with business state, SQL visibility, broker becomes non-critical, 5 s polling latency, needs a relay + dedup. BullMQ: scheduling/delays/priorities/concurrency out of the box, job dashboards, but enqueue is a separate step from commit (the stranded-derivation gap) and Redis durability is weaker than WAL. Verdict: outbox for "must not lose side effects" (provisioning, revocations), queue for "must schedule and pace work" (AI, notifications) — and traverse's notification ledger is both (queue triggers, outbox-shaped state).

4. Concurrency control. Zoth: CAS conditional updates + SKIP LOCKED claims + advisory locks. Traverse: unique-constraint dedup + P2002 handling + SKIP LOCKED lease claims + set-once updateMany. Verdict: identical primitives, different mixes — because the shapes differ (state machines vs event ingestion), not the philosophy (Day 32).

5. Multi-tenancy vs single-tenant. Zoth: tenant column + query scoping + per-tenant encryption + tenant-keyed limits + cross-tenant regression tests (Day 40). Traverse: single tenant, so the isolation budget went into user isolation (device revocation, per-user keys, block visibility) and abuse prevention (Day 89). Verdict: the same defensive instincts at different scopes — and the honest note that zoth's discipline (every query tenant-scoped) is what a reviewer should check first.

6. Observability. Both: OTel → Better Stack, trace context propagated across async boundaries (zoth through message headers, traverse through requestContext), logs correlated with traces. Difference: zoth's spans cross process boundaries; traverse's live in one process but cover the queue hops via job metadata. Verdict: same principle (correlate everything), sized to topology (Day 84).

The closing line for a comparative round: "Both systems follow the same four rules — the database is the source of truth, side effects are idempotent and claimed rather than locked, coordination comes from constraints instead of services, and every component earns its place with a measured need. The differences are all consequences of the workload: human-paced state machines versus latency-sensitive ingestion." That sentence is the whole course in miniature.