Use Cases on Inorderly.com

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.