Laith Al Enooz
← Trading platform

INGOT Brokers · production trading core

Trace a request through the trading core

A résumé bullet says “100K+ concurrent users.” That’s easy to write and hard to believe. So here is the actual shape of it — one order, followed service by service, with the decisions that keep the hot path fast and everything else honest. Scroll, and the system assembles around the request as it moves.

orders fills events Clients 100K+ concurrent Order Execution Position Mgmt Kafka bus Risk Redis cache / session

the system, at rest

  1. 01 / 07

    A request arrives

    A client places an order. At peak the platform holds a six-figure pool of concurrent connections, so the entry point can never become the bottleneck — every order lands on the execution path the same way under calm and under load.

    100K+ concurrent

  2. 02 / 07

    Order execution

    Execution is the hot path, so it owns one job and owns it completely: validate, match, and fill. It never loses an order and never double-fills — the guarantees that let everything downstream trust what it produces.

    validate · match · fill

  3. 03 / 07

    Positions update in real time

    A fill flows straight to position management so a trader’s exposure is correct the instant the order completes — not on the next poll. This hop stays on the hot path because a stale position is a wrong position.

    on the hot path

  4. 04 / 07

    Events leave the hot path

    Everything that doesn’t need to block the fill is emitted as an event onto Kafka. This is the decoupling that keeps execution fast: the hot path publishes and moves on, while the rest of the system catches up asynchronously.

    sub-100ms inter-service

  5. 05 / 07

    Risk evaluates asynchronously

    Risk consumes from the bus and reads positions out of band. It does heavy work — exposure, limits, surveillance — without ever sitting between the client and the fill, so a slow risk check can never slow an order.

    off the hot path

  6. 06 / 07

    Hot reads stay off the database

    Session and frequently-read state live in Redis (the dashed path — a lookup, not a step in the flow), keeping hot reads off the primary database so it’s free to do the durable, transactional work only it can do.

    cache / session

  7. 07 / 07

    The whole system, at rest

    Every order state transition is recorded as a full audit trail — non-negotiable for a regulated venue and the thing that lets operations trust the numbers. The execution patterns here became the reference design adopted across multiple backend teams.