Realistic Workloads
There is no end to abstract number-chasing in distributed systems. If a project says it handles 1M events, someone will ask why not 10M.
Realistic Workloads
causal-order does not frame scale that way.
The Better Question
The real question is not:
- how many events exist in the whole system?
It is:
- how many events need to be interpreted together to answer one operational question honestly?
Typical Work Units
In practice, that often means:
- one account history
- one device sync history
- one incident timeline
- one replay batch
- one tenant slice
- one bounded stream window
Practical Design Targets
For this project, a useful mental model is:
10kshould feel easy100kshould feel solid150kis a valuable corrupted-dataset stress band for hardening and visibility- named
250kbatch and stream runs are already in place as heavier operational validation, even though they are not the default lightweight guardrail story 1M+should be treated as an explicit scalability target, not a default assumption
This is not about lowering ambition. It is about staying anchored to the workloads teams actually inspect together.
The important distinction is that 100k is still the routine credible batch story, 150k is used to pressure-test anomaly-heavy and corruption-heavy workloads, and 250k now exists as an operational extended-validation layer rather than only as an idea.
That 150k band is also a believable deployment example rather than just a benchmark tier:
- a central server can be down for
4to8hours - devices or nodes keep producing events locally during that outage
- the resumed sync can create a backlog large enough that serious bounded replay is the honest operational model
For more on that distinction, see Stress Hardening.
Why Streaming Exists
If the natural workload is unbounded or too large to handle honestly as one in-memory batch, the better answer is often streaming, partitioning, or batching.
That is why orderEventStream() matters.
It gives the project a more honest model for large or continuous flows than pretending everything should be processed in one giant sort.
There is also a named streaming-250k-watermark-lag profile for heavier stream validation when you want to check beyond the main routine bands.