How a 100K daily transaction system required 22x peak capacity

A developer building a payment reconciliation service found a 22x gap between average and peak load. The case study shows why designing for peak TPS is non-negotiable for system resilience.

An engineer designing a payment reconciliation system for a service processing 100,000 transactions daily calculated the average load at one transaction per second. The math was simple: 100,000 divided by 86,400 seconds. But according to a case study published on Dev.to, during a 45-minute peak window, the system actually needed to handle 22 transactions per second. This 22x spike changes every architectural decision.

The deceptive average

Most system design discussions begin with a daily volume figure. The author of the post, writing about a payment settlement pipeline, notes the common mistake is to state a large aggregate number like "100K transactions a day." While this sounds impressive, it obscures the actual engineering challenge. Spreading that load evenly over 24 hours results in a trivial workload of roughly one transaction per second. A system designed for this average load would be simple, likely a single-threaded process run by a cron job.

Mapping the workload's actual shape

Real-world systems do not experience uniform load. The case study describes an end-of-day reconciliation service for an instant payment rail. Traffic was not a smooth stream. It built slowly during the day and then spiked sharply as merchants settled books and payroll batches were triggered. The most intense period was the final reconciliation window, when an external bank sent its ledger data in a concentrated burst. This is the workload's true shape, defined not by the 24-hour average but by its most intense, compressed peak.

A 22x engineering reality

Measuring this peak window revealed the critical gap. The naive average was one transaction per second. The actual peak throughput required was 22 transactions per second, concentrated in a 45-minute window. The 22x gap between the average and the actual peak is the difference between a marketing number and an engineering requirement. Designing for a 22 TPS burst forces a completely different set of architectural choices. Questions about thread pool sizing, message queues, and database connection limits move from academic to critical. Idempotency becomes non-negotiable to handle the inevitable retries that occur under heavy load.

What we'd change

The post’s advice is a timeless principle of backend engineering. To make it a broader founder playbook, it needs context beyond payment rails. For a consumer SaaS, the peak might follow a marketing email blast or a viral social media post. For a B2B productivity tool, it is likely 9 AM on Monday morning. The principle is the same: identify the business driver of the peak, not just the technical result.

Modern infrastructure, particularly serverless functions, can absorb traffic bursts more gracefully than provisioned servers from a decade ago. But this does not eliminate the problem. Serverless execution simply moves the bottleneck. A function may scale to handle 22 TPS, but the database it connects to or the third-party API it calls likely has its own limits. The core task remains modeling the entire system's capacity, especially its dependencies, against the peak load. Founders without existing traffic data can model this by analyzing user journey maps to predict high-volume actions or by studying benchmarks from comparable products.

Landing

Calculating average load is a planning exercise. Calculating peak load is an engineering requirement. The distinction determines whether a system survives its own success. For founders, quoting daily volume is for a pitch deck. Designing for the peak is for the product. Underestimating the violence of a traffic spike is a common, and often fatal, early-stage technical error.

The investor read

This tactic is a proxy for technical diligence. A founder who discusses peak transactions per second (TPS) instead of daily active users demonstrates operational maturity and an understanding of true scaling costs. For any transaction-heavy business (fintech, adtech, logistics, API-first SaaS), an investor's key question should be about peak load architecture, not just aggregate volume. A failure to plan for peak load signals a future capital need for an expensive, emergency re-architecture. Conversely, a clear strategy for handling traffic bursts is a positive signal of capital efficiency and lowers technical risk. This isn't a lifestyle vs. venture metric; it's a fundamental competence check.

Pull quote: “The 22x gap between the average and the actual peak is the difference between a marketing number and an engineering requirement.”