Posts on Inorderly.com

How Inorderly Was Tested With Shuffled Arrivals and Killed Runs

Sun, 18 Oct 2026 00:00:00 +0000

Inorderly makes one promise above the rest: the same events give the same output, byte for byte, however they arrived. That’s an easy thing to say and an easy thing to get slightly wrong, so most of the tests do nothing but try to break it. They shuffle events, repeat them, cut the stream with snapshots, and kill the process in the middle of a run.

Every result below comes from the files in test/results, recorded from version 0.1.1 on a two-core 2.1 GHz Xeon cloud machine running Linux, with Go 1.24. The same tests run on every push, on Linux, macOS and Windows.

Inorderly 0.1 Turns Late, Duplicate and Out of Order Events Into One Repeatable Sequence

Sun, 18 Oct 2026 00:00:00 +0000

Events don’t arrive the way they happened. A webhook gets retried and the same order turns up twice. A payment service’s clock runs behind the checkout’s, so the payment looks older than the order it pays for. A price feed delivers tick 88 before tick 87. Every pipeline that takes events from more than one place has some code to deal with this, and that code usually gives a slightly different answer each time it runs.

Making a Ledger, a Billing System and an Audit Agree on Every Balance

Sun, 18 Oct 2026 00:00:00 +0000

Two systems that read the same events should end up in the same state. They often don’t, and the reason is rarely the code. It’s the order. A withdrawal that comes before a deposit gets declined; the same withdrawal after it goes through. If the ledger and billing see those two in a different order, they disagree on the balance, and both are right about what they saw.

This worked example has four branches and 300 accounts. Over four hours they produce 100,929 transactions: deposits, withdrawals that are declined when the balance is short, and 929 reversals that undo an earlier transaction and name it as their parent. The branches’ clocks are up to 0.8 seconds apart, so 77 reversals are stamped before the transaction they undo. The ledger and billing each get the transactions through their own queue, with their own delays. Later an auditor replays the four branch logs. Those were exported at least once, so 2,510 of their lines are there twice.

Merging Two Lossy Market Data Feeds Into One Tick Stream With Exact Gaps

Sun, 18 Oct 2026 00:00:00 +0000

Exchanges send market data twice, over two lines usually called A and B. Each line drops a packet now and then, and rarely the same one. Take both, keep the first copy of each tick, and you get a fuller feed than either line alone. That’s the theory. The merge code is where it gets awkward.

This worked example sends 150,000 ticks for three symbols over two lines. Each line loses about 2% of its ticks at random. Line A also goes quiet for four seconds and line B for three, at different times. Line B runs a few milliseconds behind A. In the end 143,458 ticks came on both lines, and 84 came on neither.

Ordering Retried Webhooks So Payments Never Come Before Their Orders

Sun, 18 Oct 2026 00:00:00 +0000

A shop takes its events as webhooks. Checkout sends the order. Payments sends the payment, and later a refund if there is one. The warehouse sends the shipment. Three services, three clocks, one provider in the middle that retries any delivery it isn’t sure about.

This worked example runs 20,000 orders through that setup. Every order gets a payment that names the order as its parent, and then either a shipment or, for about one order in twelve, a refund. The payments service’s clock runs up to a second and a half behind checkout’s, which is plenty: 3,487 payments are stamped before the order they pay for. The provider retries about 15% of deliveries, some of them twice, up to a minute and a half later. The same 60,000 events are then delivered three times, each time with different network delays and different retries.

Ordering Sensor Telemetry From Devices With Bad Clocks and Late Uploads

Sun, 18 Oct 2026 00:00:00 +0000

Sensors are the worst-behaved producers there are. Their clocks drift. Some sit behind a gateway that forwards readings in batches. Some lose their connection for a while, keep what they measured, and send it all at once when they’re back. A few readings just never arrive.

This worked example has 200 devices sending a temperature reading every 10 seconds for three hours, 216,000 readings in all. Their clocks are up to 3 seconds out. Fifty of them sit behind five gateways that forward every 45 to 90 seconds. Twenty go offline for 2 to 12 minutes and ten for 25 to 40 minutes. 634 readings are lost on the way. Each reading carries its device’s sequence number. The readings are uploaded three times, with different network delays and gateway timing each time.

What Is Deterministic Event Ordering and Why a Replay Should Give the Same Answer

Sun, 18 Oct 2026 00:00:00 +0000

Deterministic event ordering means that the same set of events always comes out in the same sequence, no matter the order they arrived in or how many times each one arrived. Feed the events in once and you get a sequence. Feed them in again next week, shuffled, with half of them sent twice, and you get the same sequence, byte for byte.

That sounds like it should be the default. It almost never is. Most systems process events in arrival order, and arrival order is an accident of networks, retries and clocks.

Where the Name Inorderly Comes From

Sun, 18 Oct 2026 00:00:00 +0000

Inorderly is two phrases run together. “In order” is the job: events lined up one after another, the way they should be. “Orderly” is the manner: calm, tidy, no surprises. Put them side by side and you get a word that describes what the engine does and how it behaves while doing it.

It also reads as a small joke. Events show up out of order, and they leave in order. The name sits right in the middle of that.