Horizontal Scaling
Also known as: Scale out
Horizontal scaling (scaling out) adds more identical instances behind a load balancer rather than making one instance bigger (vertical scaling). The constraint is whether the workload can be partitioned cleanly — shared mutable state, ordering requirements, or session affinity all push back. TantraDev's first move on a saturated single-server monolith is to find the partition key, not to upsize the box.
Concepts that travel with this one.
Architecture rarely lives in isolation — these are the terms that come up in the same conversation.
Database Partitioning
Partitioning splits a logical table into physical pieces along a chosen key — date, tenant, currency, region. Queries that filter on the partition key only touch the relevant slice; writes spread across slices instead of contending on one. PostgreSQL native partitioning (pg_partman for management) is TantraDev's default move when a single table exceeds a few hundred million rows or query latency starts climbing with table size.
CAP Theorem
The CAP theorem (Brewer) states that a distributed datastore can guarantee at most two of: Consistency, Availability, and Partition tolerance. Since network partitions are inevitable in real systems, the practical trade-off in any production design is between consistency and availability. Saying 'we are CP' or 'we are AP' is an architectural commitment, not a slogan — it dictates retry, replication, and failover behaviour.
Building a system where Horizontal Scaling is the load-bearing decision?
30 minutes on the phone, one page in your inbox — what to build, what to skip, what it will cost. You keep the audit even if we are not the right fit.