Scaling round 2: live performance telemetry, tougher write paths, and the first relational building blocks

We measure the thing that matters now

The single biggest scale risk we track is how long it takes to durably persist marketplace state. That duration - along with the size of the persisted state and event-loop responsiveness - is now measured continuously and visible to operators, with automatic alerts at warning and critical thresholds.

A new load-test harness gives us a repeatable baseline: burst-submitting 50 identical checkout requests concurrently produces exactly one order; the API stays responsive under sustained courier-GPS bursts; and a hard process kill mid-traffic recovers in about a second with no accepted order lost.

Less work per write

• Database mirror writes are now latest-wins: a burst of changes no longer queues a full rewrite per change, and the side-table refresh went from rewrite-everything to skip-if-unchanged plus batched updates.
• State serialization happens once per persist instead of multiple times, in a compact format.
• Hot telemetry-style updates (device heartbeats, search telemetry) can be coalesced away from the durable write path - order and payment writes remain synchronous and durable before we acknowledge them, exactly as before.
• Courier GPS pings now use constant-time lookups instead of scanning all orders, cutting the CPU cost per ping as the marketplace grows.

First relational building blocks - no big-bang rewrite

• A proper, ledgered schema-migration runner now manages database schema changes.
• New relational tables mirror the most safety-critical state: checkout idempotency keys with request fingerprints, processed payment-webhook events, delivery-email telemetry, latest courier positions, and an append-only money-ledger event stream.
• These are dual-written behind individual flags while the existing store remains the source of truth - the strangler pattern, not a rewrite. Duplicate-payment protections now hold even across restarts and restores.
• Personal-data rules carried over: courier locations in the new table are covered by the same GDPR erasure and export guarantees as everything else.

Safer operations

• Only one backend instance can ever mutate state: a database-level lock now refuses a second process at boot (previously enforced only by convention).
• Restarts during deploys stopped dropping requests: the proxy now briefly buffers and retries while the backend comes back.
• Refunds that stall at the payment provider are detected and paged to a human within minutes, with a documented manual procedure - money is never auto-retried.
• Log growth is capped, backup coverage was extended, and the deploy pipeline gained a stale-source guard so only reviewed, up-to-date code can ship.

Groundwork for new cities and countries

New orders, merchants, and couriers can now carry an explicit market context (country, city, zone, currency) behind a flag - the data-model groundwork for expansion beyond Bucharest, with an isolation seam and tests in place so cross-market access rules exist before a second market does.

What is deliberately unchanged

Payment gates, webhook verification, refund limits, role-based access control, GDPR flows, and the no-default-tip rule are byte-identical. Every change in this round ships with a kill-switch and a tested rollback, and an adversarial security and deploy-reliability review signed off with zero critical findings before release.