What one machine actually does
You cannot justify a distributed system without knowing what one machine delivers, because the honest answer is usually more than you need.
A handful of ceilings is enough, because you will reach for them constantly. A stateless web server handles 10,000 to 50,000 requests a second when connections are reused. Postgres, a relational database, does around 10,000 reads or 5,000 writes a second on ordinary hardware. Redis, an in-memory store, serves about 100,000 operations a second on one instance and past a million when you batch them. A single message broker moves on the order of a million messages a second, because it writes sequentially and lets the operating system serve the reads.
The spread is the point. The relational database is the smallest number on that list, which is why it is almost always your bottleneck, and why so much architecture exists to keep traffic away from it.
The numbers are also larger than people expect. A product with a million daily users generating 100 requests a second on average, perhaps 300 at peak, sits at 3 percent of one database node's read ceiling. Sharding that system is a self-inflicted wound.
Which axis binds first
The ceilings tell you which axis to scale. Web tier over capacity: add instances behind the load balancer, since it holds no state. Database read-bound: add copies or a cache, both cheap. Database write-bound: now you are in sharding territory, because every write needs a single authority and the only way out is splitting the key space.
These are rough sizes, right to within a factor of ten, not as promises. One fat query drags a database to 500 reads a second, and a tuned machine on fast storage beats 10,000. Benchmark before betting the roadmap, and estimate with the reference figures so you know which bets deserve a benchmark.
Worked example
Marcus inherits a food ordering platform where a previous team sharded MySQL across 8 nodes for scale. He pulls the traffic numbers: 40,000 orders on the busiest day ever, plus browsing, peaking at 220 requests per second, of which about 30 are writes. One Postgres instance handles 5,000 writes per second, so the platform runs at under 1 percent of a single machine's write ceiling, spread across 8. Meanwhile the sharding layer has caused two outages, cross-shard reporting needs a nightly ETL job, and every schema migration takes 8 times as long. Marcus spends a quarter consolidating to one primary, two replicas, and a Redis cache. Latency at p99, the figure 99 requests in every 100 come in under, improves because queries stopped hopping between shards. The fleet shrank and got faster, exactly what the reference numbers predicted before anyone benchmarked anything.