CoralSequencer implements the sequencer architecture, a messaging architecture widely used by financial firms to build deterministic distributed systems. Its core idea is simple: all nodes read all messages in the exact same order, always. From that single rule, the system gets consistency, replayability, high availability, and a clean way to evolve many independent services without losing a single authoritative timeline.
This article is a quick summary of the 1-hour video below. The video has a long demo section that you can skip if you want to. You can also watch it on YouTube by clicking here. Note: Contrary to the YouTube video, the video below has no ads.
One Stream, One Order
The most important characteristic of the sequencer architecture is that there is only one ordered event-stream. Nodes do not subscribe to different topics that can race with each other or arrive in different orders. Every node receives the same messages in the same sequence, and each node can quickly ignore the messages it does not care about.
That is what makes the architecture deterministic. If two nodes run the same code, consume the same ordered input, and use the same sequenced clock, they will build the same state. A gateway, a position monitor, a risk engine, a logger, or a backup instance can all observe the same history and reach the same conclusions from it.
This also makes the whole system easier to reason about. When something happens, it happened at one exact sequence number. There is no ambiguity about whether one service saw an event before another service or whether two streams crossed in an unexpected way.
The Sequencer Is The Source Of Truth
At the center of the architecture is the sequencer. Nodes send upstream messages to it, and the sequencer assigns the final order to the downstream messages. Once a message is sequenced and timestamped, it is distributed to every node and becomes part of the event-stream.
This does not mean every node has to do the same work. It means every node has the same input. An order port can care about client orders, a gateway can care about exchange routing, and a position monitor can care only about executions. They all read the same stream, but each one applies its own logic.
Because the sequencer defines the order, the rest of the system can run in parallel without losing consistency. Nodes can live on different CPU cores, different machines, or different data centers, while still sharing the same ordered reality.
Replay Makes State Recoverable
A node that starts late does not need a special recovery path. It can rewind from the beginning of the session, or from a known committed sequence number plus snapshot, and rebuild its state from the same messages that every other node already processed.
This is why deterministic clusters become natural in this architecture. A backup gateway, backup position monitor, or backup sequencer can start, rewind, catch up, and then sit at the same state as the live instance. If one machine fails, another instance can already have the same state because it has been consuming the same ordered input.
The same idea is useful for debugging and auditing. The archiver saves the full event-stream to a binary session file, and that file can be replayed later. A trading day can be reprocessed offline, without the original network, sequencer, or live services. The session file becomes the exact record of what happened.
The Supporting Components
The sequencer is the central ordering component, but the full architecture includes other important actors. Replayers provide gap filling and rewinding. If a node misses a packet, it asks a replayer for the missing message. If a node joins late, it rewinds from a replayer and catches up.
The archiver persists the full stream to a binary file. The logger writes a human-readable view of the same stream. The bridge allows nodes to connect over TCP, including across networks, data centers, or cloud environments. The dispatcher distributes messages locally through shared memory when many nodes run on the same machine.
These components keep the model practical. The sequencer stays focused on ordering, while replayers, archivers, bridges, loggers, and dispatchers handle recovery, persistence, connectivity, visibility, and local distribution.
Transport Can Change Without Code Changes
CoralSequencer can run with reliable multicast UDP, TCP, shared memory, or combinations of transports. The application code does not need to change when the transport changes. A deployment can use multicast UDP on premises, TCP in the cloud, shared memory inside a machine, or bridge-to-bridge TCP between regions.
Reliable multicast UDP is the natural fit when the infrastructure supports it, because the sequencer can send a message once and let the network distribute it efficiently. When multicast is not available, CoralSequencer can use a sequenced TCP protocol so the same architecture can still run in cloud or external-client environments.
The important point is that transport is an infrastructure decision, not an application design rewrite. The same nodes can keep the same logic while the deployment changes underneath them.
Production Features Matter
CoralSequencer includes features that are small individually but very important in production. Replayers can be discovered over multicast. If a chosen replayer disappears, a node can fall back to multicast discovery and choose another one. Large messages can be fragmented into multiple packets and reassembled transparently for the application.
Nodes can also rewind from a local session file instead of going through the network. When a local replayer file is available, startup can be much faster, especially for sessions with millions of messages. For some nodes, committing a sequence number can avoid unnecessary reprocessing after restart.
For very long sessions, a system can also combine snapshots with rewinding from a chosen sequence number. The preferred model is still to rebuild from the event-stream when possible, but CoralSequencer gives operators and developers options when the operational reality requires them.
Fairness, Batching, And Deterministic Time
The sequencer architecture needs to be fast, but it also needs to be fair. CoralSequencer lets nodes send multiple messages in flight, but it limits how many unacknowledged messages a node can place into the sequencer. This prevents one node from flooding the input path and taking over the system.
At the same time, CoralSequencer batches aggressively. When many messages are flowing, it can place multiple application messages into the same packet. This improves throughput and can reduce the effective cost of sending each individual message.
Time is also deterministic. Instead of every machine using its own local clock and creating different results during replay, the clock advances through the event-stream itself. If a message was timestamped during the live session, replaying the same session later can produce the same timestamp and the same state again.
Why Financial Firms Like This Architecture
Financial systems often have many moving parts: order entry, gateways, matching engines, risk checks, position monitors, loggers, reporting nodes, and backup instances. These components need to react in real time, but they also need to stay consistent with each other.
The sequencer architecture gives those systems a single ordered history. Nodes can be added, restarted, upgraded, or moved without changing the rest of the system. A slow node can lag and recover without stopping faster nodes. A new node can join, rewind, and become useful without requiring a special synchronization protocol.
That is the main reason the architecture has remained relevant for financial systems for so long. It gives low latency, parallel execution, operational visibility, replayable history, and deterministic recovery without forcing every service to coordinate directly with every other service.
Why CoralSequencer?
CoralSequencer was designed for high performance and determinism. The sequencer is single-threaded by design, so the critical path avoids locks, context switches, cache contention, and coordination between worker threads. That single thread can be pinned to one isolated CPU core and allowed to spin for ultra low latency.
The same single-threaded model also helps determinism. With multiple threads, the kernel can time-slice execution in different ways, creating different combinations of execution paths. With one critical thread, the order of execution is explicit, predictable, and tied to the event-stream. Even the clock and the timers are deterministic in order to accomplish a true deterministic finite state machine.
Its reliable multicast transport is based on the MoldUDP protocol, a established protocol in the industry for this kind of architecture and a protocol that has been used for decades in financial markets. MoldUDP keeps the normal path extremely efficient while still allowing missed packets to be recovered through replayers. At the same time, CoralSequencer is not limited to multicast: the same application code can be deployed over TCP (SoupBinTCP), shared memory, or combined TCP and UDP transports, with this choice made at the deployment/configuration level, never at the code level. For more information you can check this article: On-Premises and Cloud Infrastructure with CoralSequencer.
CoralSequencer has been battle-tested in production for more than 10 years and has been used by investment banks, market makers, hedge funds, and other demanding financial institutions. Many of them are big and famous names recognized by the industry.
That combination is what matters: a simple single-threaded hot path, an industry-proven reliable multicast protocol, deployment-level transport flexibility, deterministic replay, and a long production history under real financial workloads.
Conclusion
CoralSequencer turns a distributed system into a set of deterministic nodes reading the same ordered stream. The result is a system where state can be rebuilt, failures can be handled with clusters, components can evolve independently, and the full session can be archived and investigated later.
The architecture is powerful because it keeps the rule simple: all messages, all nodes, same order. Around that rule, CoralSequencer adds the production pieces required to make it practical: reliable transports, replayers, archivers, bridges, dispatchers, batching, fairness, deterministic clocks, large messages and flexible deployment options.