An Exchange That Survived Its First Listing Day

Order submission began with authentication, market status and syntactic validation, followed by a funds reservation against the account ledger. Client-supplied idempotency keys allowed a timed-out request to recover its original result instead of creating another order. Accepted commands entered a sequenced stream consumed by the matching component, whose deterministic state transitions produced executions, cancellations and rejections. The API did not infer final order state from whether an HTTP response had returned. Clients could query the durable order record, and internal services consumed ordered events with gap detection. A missing sequence stopped that partition from inventing continuity and raised an operational exception.

Balance reservation and execution posting were connected without pretending to share a transaction. The ledger recorded reserved and available positions through balanced entries, while a transactional outbox published committed changes. Execution consumers posted transfers using the execution identifier as an idempotency key, then released any residual reservation when an order closed. Reconciliation compared engine orders and executions with reservations and ledger entries, exposing orphaned or delayed state by source identifier. Corrections used compensating ledger entries and linked operational decisions; balances were never repaired by updating a current total. This provided a history capable of explaining both ordinary trading and recovery after an interrupted consumer.

Deposits moved through observed, attributed, pending and available states. Chain listeners and custody providers could resend notifications or revise confirmation status, so adapters normalised external events and retained their source identity. Crediting occurred through an idempotent ledger event after policy conditions were met, not whenever a webhook arrived. Reorganisations, unsupported transfers and ambiguous destination data entered explicit exception paths. The displayed balance came from the ledger, with external wallet state reconciled against it as a separate control. This prevented provider availability or eventual chain indexing from determining whether internal accounting history existed.

Withdrawals began as controlled intents. Validation, account reservation, policy checks, approval where required, signing submission and external confirmation were separate transitions with immutable timestamps and actors. A timeout after submission did not authorise automatic resubmission until the provider or chain had been queried using the original reference. Fee treatment and returned transactions generated ledger entries rather than editing the withdrawal amount in place. Custody credentials stayed behind a narrowly scoped adapter and were not available to general exchange services. Operational tooling exposed stuck states and safe next actions without revealing signing material or offering a generic force-complete button.

Market data was derived from the authoritative engine event stream. Snapshots carried a sequence position, and incremental updates allowed clients to detect a gap and resynchronise rather than continue displaying an invalid book. The websocket tier bounded per-connection buffers and disconnected clients that could not consume safely; it did not allow slow subscribers to exhaust shared memory. Public trade, ticker and book views could be degraded independently from authenticated order entry. Internal monitoring compared publication lag with engine position, making stale but apparently healthy connections visible before users reported contradictory screens.

Load testing modelled behaviour rather than a single request rate. Scenarios included concentrated order placement, cancellation waves, reconnecting market-data clients, repeated idempotent requests and consumers recovering a backlog. Fault injection delayed event handling, interrupted the custody adapter and restarted stateful components from snapshots plus logs. Tests asserted invariants after recovery: no unexplained ledger imbalance, no execution applied twice, no order progression across a sequence gap and no withdrawal resubmitted because of an ambiguous response. Capacity decisions followed the measured saturation point of each bounded queue, with explicit rejection or backpressure before the component became unavailable in an uncontrolled way.

A market definition contained base and quote assets, precision, minimum increments, fee rules, status and external identifiers. Configuration was validated as a coherent version, reviewed and promoted through environments rather than patched directly in production. Readiness checks confirmed custody support, ledger accounts, deposit and withdrawal policy, market-data channels, monitoring and operational ownership. The market progressed through disabled, cancel-only and trading states under authorised commands. Opening was therefore reversible at the venue-control level even though already accepted executions remained durable facts. Protective action stopped new risk without rewriting completed activity.

The listing rehearsal exercised the same runbook and permissions intended for live operation. Dashboards were organised around invariants and queues: event lag, sequence gaps, unmatched reconciliation items, wallet exceptions and rejected commands. Alerts linked to a specific operational state and documented response rather than reporting undifferentiated infrastructure noise. During opening, decision records captured configuration version, readiness acceptance and any control change. Afterwards, reconciliation ran across orders, executions, fees, ledger balances and custody observations before routine operation resumed. The listing held because the system had defined how to refuse, pause, replay and explain work, not because every dependency was assumed to remain fast and available.