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.

About

Mon, 01 Jan 0001 00:00:00 +0000

inorderly.com is the home of Inorderly, a small Go engine for deterministic event ordering. It takes events that arrive late, twice or out of order and releases them as one sequence. Give it the same events again, in any order and with any repeats, and it writes the same sequence, byte for byte.

Why It Exists

Events rarely arrive the way they happened. A webhook provider retries, so an order shows up twice. Two services stamp events with clocks that disagree, so a payment looks older than the order it pays for. A feed handler sees tick 88 before tick 87. Most teams patch this with a dedupe table, a sort buffer and a timeout, and the patch mostly works.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

inorderly.com would like to hear from:

Anyone trying Inorderly out. What worked, what got in the way, and what you used before.
Anyone who found a bug. Above all, two runs over the same events that gave different output.
Anyone with an idea for something Inorderly should do next.

Write to info@inorderly.com.

Bug reports are also welcome on GitHub. It helps to include what inorderly version prints, your operating system, the flags you used, and a few made-up events that show the problem. Please don’t send real customer data.

Download Inorderly

Mon, 01 Jan 0001 00:00:00 +0000

Each archive below holds the inorderly command with the license files and README. There’s nothing else to install. The links always point to the latest release.

System	Download
Linux, x86-64	inorderly_linux_amd64.tar.gz
Linux, ARM64	inorderly_linux_arm64.tar.gz
macOS, Apple silicon	inorderly_darwin_arm64.tar.gz
macOS, Intel	inorderly_darwin_amd64.tar.gz
Windows, x86-64	inorderly_windows_amd64.zip

Checksums are in SHA256SUMS. Every release is listed on GitHub.

Install

On Linux or macOS:

tar -xzf inorderly_linux_amd64.tar.gz
sudo mv inorderly /usr/local/bin/
inorderly version

The binaries are pure Go and need no system libraries. The macOS ones aren’t signed by Apple, and macOS may ask you to allow them the first time. You can also clear the flag yourself:

Quick Start

Mon, 01 Jan 0001 00:00:00 +0000

This takes about five minutes. You’ll feed the same events to Inorderly in different orders, with repeats, and see the same output and the same hash come back every time. You need the inorderly command from the download page.

1. Write Some Events

Inorderly reads one JSON event per line. Save these five lines as events.ndjson. They’re an order, its payment and its shipment from three services, a second order, and the first order again, the way a retried webhook would send it:

Reference

Mon, 01 Jan 0001 00:00:00 +0000

The command, its files and the Go packages, for Inorderly 0.1. The contract on GitHub has the exact ordering rules.

The Command

inorderly [flags]           read NDJSON events, write them in order
inorderly version           print the version as JSON
inorderly demo [flags]      run the self-checking demo and print its report

Flags

Flag	Default	Meaning
`-in FILE`	standard input	An input file. Repeat it to read several files a line at a time in turn: one line from the first, one from the second, and so on. `-` is standard input.
`-out FILE`	standard output	The ordered output.
`-window N`	0	How far, in event-time units, an event may arrive behind the newest time seen.
`-hold N`	the window	How long past its own time an event waits for a parent.
`-remember N`	0 (always)	How long behind the watermark released events are remembered, for duplicates and parents.
`-rejects FILE`	none	Late, conflicting and invalid lines, one JSON object each.
`-state DIR`	none	Checkpoints. A run killed part way carries on from the last checkpoint when started again with the same flags. Needs `-in` files and an `-out` file.
`-checkpoint-every N`	10000	Input lines between checkpoints.
`-stats FILE`	standard error	Where the summary goes.
`-strict`	off	Exit with status 3 if any line was late, conflicting or invalid.

Input

One event per line, as JSON. Blank lines are skipped. Lines may end in \n or \r\n, and the last line needs no line ending. A line longer than 16 MiB is invalid. Unknown fields, a missing producer or time, a fraction where an integer belongs, a key repeated in one data object, or anything after the event on the same line make the line invalid.