Comparisons

Ten pairs that get conflated in real conversations. Neither column wins — what decides is the requirement. Each record leads with the confusion, because the confusion is the reason the record exists.

Authentication vs Authorization Server sessions vs Tokens ORM vs Raw SQL Optimistic vs Pessimistic concurrency Synchronous vs Asynchronous communication Offset vs Cursor pagination Local (in-process) vs Distributed cache Monolith vs Microservices Horizontal vs Vertical scaling At-least-once vs "Exactly-once"

Horizontal vs Vertical scaling

What people get wrong about this pair

Scaling out is treated as the sophisticated answer and scaling up as the embarrassing one. Vertical scaling is often the correct next step: it requires no code change, no statelessness work and no distributed reasoning. And scaling out does nothing at all if the bottleneck is the shared database every instance queues on.

Scale out — more instances

Use it when

Stateless request handling where load grows beyond one machine, and where redundancy is itself a requirement.

Scale up — a bigger instance

Use it when

When the bottleneck is one thing that cannot be split — a primary database, a memory-resident working set, a single-writer component.

Dimension	Scale out — more instances	Scale up — a bigger instance
Code prerequisite	Statelessness, externalised sessions and locks	None
Redundancy	Comes with it	None — one machine is one failure
Ceiling	Usually the shared dependency behind it	The largest instance available
Downtime to apply	None — add instances	Usually a restart or failover
Effect on the database	More connections; the pool math changes	Unchanged connection count
When it fails to help	When the bottleneck is shared and singular	When the work is genuinely parallel and huge