Trading, Market Data & Digital Assets challenge
Order books, matching engines and what market data actually is.
Trading & Transaction Systems · Interactive Transaction Model
Transaction Throughput Calculator
Peak load · Utilisation · Headroom
Change the shape of the day and see what the platform actually has to survive — average rate, busy-hour rate, the worst second, and how much headroom is left against the rated capacity. The same daily volume can ask for very different infrastructure.
Total across all channels on a normal business day, not a quiet one.
Per cent of the day's volume landing in the busiest hour. Evenly spread would be about 4%; consumer payments often reach 10–20%.
Ratio of the busiest second to the average second inside that hour. Batch cut-offs, market opens and campaign sends push this well above two.
TPS
Transactions per second the system is claimed to sustain — the figure to be tested, not trusted.
Start from an example: Five million a day, 18 per cent in the busy hour, burst of three →
- —Per day
- —Busy hour
- —Burst
- —Peak second
- —Rated capacity
- —Peak second
- —Utilisation at peak
- —Headroom
- —Busy-hour average
- —Daily average
- —Peak to average
Move a parameter and the platform answers: what the worst second of the busiest hour asks for, and what is left of the rated capacity when it does.
The link carries the figures you entered, in the part of the address that is never sent to a server.
Change one assumption at a time. The model updates from the same calculation used for the reported result.
Try this
Keep daily transaction volume fixed. Change only the busy-hour concentration and burst factor and see how different the required peak capacity becomes.
How the model works
- The dayA daily volume averages out to a rate that no system ever actually sees. It is the number the business quotes and the least useful of the three.
- The busy hourTraffic is not flat. The share of the day that lands in the busiest hour is the first thing that turns an average into a load — a perfectly flat day would put about four per cent of it in each hour.
- The worst secondInside that hour there is a second worse than the rest. The burst factor is that second, and it is what the platform has to survive: capacity is sized for the peak, not for the average.
- What is leftUtilisation is the peak second against the rated capacity, and headroom is what remains. The volume that uses it all up is worth knowing before it arrives.
Need capacity you can defend under load?
We can model your real arrival profile, test the path end to end, and build the instrumentation that shows the peak coming before it arrives.
Calculation basis 4 steps · view the method →
Daily average = transactions per day ÷ 86,400 seconds—Busy-hour average = daily volume × busy-hour share ÷ 3,600 seconds—Peak second = busy-hour average × burst factor—Utilisation = peak second ÷ rated capacity—
Assumptions & limitations Screening estimate for capacity planning and headroom review · 6 assumptions →
This is a screening estimate of arrival rate, not a performance model. Real systems are limited by the slowest dependency, by locks, by queue behaviour under saturation and by what happens during retries — none of which appear here. Confirm with load testing against the real path before relying on the headroom.
- Arrival is treated as a rate, not as a queue: nothing here models latency, contention or backlog.
- The burst factor is applied uniformly; real bursts are shaped by the event that causes them.
- Retries, reversals and duplicate submissions are excluded, though they land in the same peak.
- Rated capacity is taken at face value and is usually measured on a favourable path.
- Batch, settlement and reporting load running alongside the transaction path is excluded.
- No allowance is made for degraded operation with a node or region out.
Worked examples
- Five million a day, 18 per cent in the busy hour, burst of three
Open with these figures → - The same system after volume doubles
Open with these figures →
What this model reveals
Daily volume is an incomplete measure of system capacity. The same number of daily transactions can create very different infrastructure requirements depending on how concentrated the busy hour is and how severe the short bursts become. This model separates average load from the moments the platform actually has to survive.
Go deeper
Modern IT Systems challenge
Event streaming, brokers, scaling and consistency, without any code.
PopularityExchange case study
A real-time trading platform shipped as web and Telegram Mini App.