A financial ledger system needs every transaction across all accounts to be applied in one single, globally agreed-upon order (not just per-account order), but the team is using a partitioned event log for throughput. What architectural approaches let you get a global order guarantee out of a system whose native primitive only guarantees per-partition order?

## Why global order fights partitioning **Global ordering** — a single, agreed-upon sequence covering every event in a stream, regardless of which entity it belongs to — is fundamentally in tension with partitioning, because partitioning's entire value proposition is parallel, uncoordinated writers and readers, while a global order requires exactly the opposite: a single point that can say definitively "this happened before that." There is no way to have both unconditionally; every real design either - narrows the scope where true parallelism happens, - or accepts a weaker (reconstructed, approximate, or delayed) notion of order in exchange for keeping parallelism elsewhere. The question is really about which part of the system pays that cost, and how. ## Pattern one: one writer for the order-sensitive stream The first and simplest pattern is to not partition the order-sensitive stream at all: route every event needing global order through a single partition (or a single-writer system entirely, like one strongly-consistent relational table with an auto-incrementing primary key). This trivially gives you a true, unambiguous global order because there is, by construction, only one writer assigning position. The cost is that you've fully given up partition-level parallelism for that stream — throughput is capped by whatever one partition/one writer can sustain. This is entirely reasonable when the volume that truly needs global order is a small fraction of total system volume: a financial ledger's core double-entry postings might be low-enough-volume (thousands, not millions, per second) that a single well-tuned partition or a single ACID database transaction log handles it comfortably, even while a much higher-volume stream of related-but-not-order-critical events (view logs, notifications) is fully partitioned elsewhere. ## Pattern two: sequence before fan-out The second pattern keeps partitioning for parallel writes but inserts a single point of sequencing before fan-out — - a sequencer service, - a strongly-consistent counter (e.g., backed by a consensus system like ZooKeeper/etcd, or a database sequence), - or a designated "sequencing" partition — which assigns each event a strictly increasing global sequence number at the moment it's accepted, and only then is the event fanned out to whichever partition its entity key routes it to for parallel downstream processing. Consumers reading multiple partitions in parallel can now reconstruct the true global order after the fact by sorting on that embedded sequence number, even though they consumed the events out of order relative to each other in real time. The cost here is that the sequencer itself is a serialization bottleneck and a single point of failure — every write passes through it before fan-out, so its throughput ceiling becomes the system's ceiling for ordered writes, and its availability becomes a hard dependency. This is roughly the pattern behind Google Spanner's globally consistent transaction ordering, or simpler bespoke "ticket dispenser" services some financial systems build specifically to hand out monotonic sequence numbers before distributing work. ## Pattern three: reconstruct order downstream The third pattern flips the trade-off: let writes happen fully in parallel across partitions with no coordination at write time, tag each event with a timestamp (ideally a high-resolution, monotonic producer-side clock, or a logical clock like a Lamport timestamp that captures causal relationships more reliably than wall-clock time across machines), and reconstruct approximate global order downstream via a **windowed merge** — an aggregator consumer reads from all partitions, buffers events for a bounded window (say, 2 seconds) to allow for skew between partitions' arrival rates, then emits them re-sorted by timestamp. This preserves full write-side parallelism and avoids a single point of failure, but the resulting order is only as good as the clock synchronization and the buffering window: events can still be misordered if actual skew exceeds the window, and every consumer pays the added latency of the buffering step. This pattern is common in log aggregation and observability pipelines (e.g., merging distributed traces or logs from many sources into one chronological view) where "mostly right, with bounded delay" is an acceptable trade for a human debugging a timeline, but would be unacceptable for something like double-entry bookkeeping where "mostly right" ordering could apply a debit before its corresponding credit is even validated. ## The three side by side | Approach | Where the cost lands | |---|---| | route every event needing global order through a single partition | throughput is capped by whatever one partition/one writer can sustain | | a single point of sequencing before fan-out | the sequencer itself is a serialization bottleneck and a single point of failure | | a windowed merge, emits them re-sorted by timestamp | every consumer pays the added latency of the buffering step | ## Pick per stream, not per system The principal-level judgment call is recognizing that these three patterns aren't mutually exclusive and picking per-stream, not per-system: a real financial platform typically uses pattern one or two for the narrow slice of truly order-critical ledger postings (where correctness demands it and the volume is manageable), while everything else in the same platform — analytics events, notifications, audit logging not requiring strict cross-account ordering — stays fully partitioned by entity key for maximum throughput. Conflating the two, either by trying to force the entire platform through a single global sequencer "to be safe," or by assuming partitioned-and-keyed ordering is "good enough" for the ledger core without checking, are both the failure modes principal engineers are expected to catch in a design review before either becomes a production incident — the former as an unnecessary throughput ceiling, the latter as a silent correctness bug (e.g., an interest-accrual job crediting an account before a same-instant withdrawal debited it, because the two events landed on different partitions with no enforced relative order).