Why is everything so scalable?

Premature scalability vs actual needs

• Many argue most apps won’t hit serious scale; 10k daily users / ~1k TPS is routinely manageable on a single modest server or small cluster.
• Over-architecting (Kafka, Kubernetes, CQRS, distributed NoSQL) for hypothetical future loads often kills early agility and makes inevitable product pivots painful.
• Others warn that completely ignoring scale can backfire (e.g., bcrypt-heavy auth on a tiny VPS, school‑year registration spikes); you do need a basic sense of expected traffic and some stress testing.
• Several note that “users/TPS” is often the wrong metric; workload complexity and write patterns matter more.

Monoliths, modular monoliths, and microservices

• Strong support for “modular monoliths”: single deployable unit, clear internal module APIs, explicit boundaries that could become services later.
• Microservices are seen as frequently misused: over-distribution, network as default boundary, “distributed monoliths” with tight coupling and many fragile inter-service calls.
• Some emphasize that monolith vs microservices is orthogonal to deployment frequency; slow monolith deploys are usually process/CI issues, not architectural inevitabilities.
• Counterpoint: microservices can help organizational scalability and ownership (1 service ↔ 1 team) and allow independent deploys, but this only works if boundaries and protocols are designed well.

Cloud, serverless, and cost dynamics

• Many anecdotes of simple products implemented as sprawling AWS/Azure stacks (Lambda, S3, Cognito, many services) costing hundreds or thousands per month under low load.
• Others report the opposite: well‑designed cloud/serverless setups providing cheap HA and resilience (especially for video, metrics, or bursty workloads).
• Free cloud credits and vendor marketing are blamed for pushing early teams into complex, sticky architectures; moving off later is painful.
• Bare‑metal/VPS proponents highlight how far modern hardware goes and how much cheaper & simpler a few beefy servers can be, especially with basic load balancing and DB replication.

Reliability, HA, and “real” scale

• Some claim scalability patterns usually increase reliability; others counter that complex distributed systems introduce many more failure modes and outages.
• There’s wide agreement you should distinguish scalability from resiliency: many early systems can accept occasional downtime rather than complex HA setups.
• True “large scale” (massive write volume, real‑time analytics, global video, IoT) is acknowledged as a different class of problem where specialized architectures (queues, Kafka, sharding) are justified.

Organizational and human factors

• CV‑driven development, “web scale envy,” tech fashion, and desire to “dress for the FAANG job” are seen as major drivers of unnecessary complexity.
• Overstaffed teams and strict role separations (architects, platform teams, devops) often generate microservice-heavy, over-engineered solutions to keep everyone “busy.”
• Several stress that good technical leadership and judgment—knowing when to stop—is more important than following any scaling dogma.