Architecture styles and scaling: monoliths, microservices and growth

There's no single "best" backend architecture. The right design depends on the size of the team, how much traffic there is, and how fast the product is changing. This lesson covers the main styles, how systems scale, and the patterns that keep them running when parts fail.

Monolith#

A monolith is one application, deployed as one unit, usually with one database. All the features (users, orders, payments, notifications) live in the same codebase.

• Strengths: simple to build, test, deploy and debug. A function call is fast and can't fail over the network. One database means transactions are easy.
• Weaknesses: as the codebase and team grow, changes start to collide, one bug can take everything down, and the whole application has to scale together.

A monolith isn't a mistake. Most successful products started as one, and many still are.

Modular monolith#

A modular monolith is still deployed as one application, but the code is split into modules with clear boundaries: orders can call payments only through a defined interface, never by reaching into its tables.

┌──────────────── one deployable application ────────────────┐
│  [ users ]  →  [ orders ]  →  [ payments ]  →  [ notify ]  │
│   each module owns its own tables and exposes an interface │
└─────────────────────────────────────────────────────────────┘

You keep the simplicity of a monolith, and if one module later needs to become a separate service, the boundary already exists. For most teams, this is the best starting point.

Microservices#

Microservices split the system into small, independently deployed services, each owning its own data and usually its own team. They communicate over the network, through APIs or events.

• Strengths: teams can deploy independently, each service can scale on its own, and a failure can be contained to one service.
• Costs: every call is now a network call that can be slow or fail. There's no simple transaction across services. Debugging needs distributed tracing, and you need mature DevOps: automated deployments, monitoring and service discovery.

Scaling: handling more load#

Vertical scaling#

Scale up: give the server more CPU and memory. It's simple and needs no code changes, but there's a limit to how big one machine gets, and it's still a single point of failure.

Horizontal scaling#

Scale out: run several copies of the application behind a load balancer. It's nearly limitless, and if one copy dies the others keep serving.

                 ┌──▶ API copy 1 ─┐
 Users ─▶ Load ──┼──▶ API copy 2 ─┼──▶ Database
          balancer└──▶ API copy 3 ─┘

Horizontal scaling only works if the servers are stateless: any copy can handle any request, because nothing about the user is kept in one server's memory. Sessions go in a shared store (Redis or the database) or in a signed token. Uploaded files go to object storage, not the local disk.

Scaling the database#

The database is usually the hardest part to scale. In the order you normally reach for them:

1. Indexes and query fixes. Often a 10–100× improvement for free.
2. Caching. Takes repeated reads off the database entirely.
3. Read replicas. Copies of the database that serve read queries while the primary handles writes. Replicas can lag slightly behind the primary.
4. Partitioning or sharding. Splitting the data across several databases, for example by customer. It's powerful but complex, so treat it as a last resort.

Designing for failure#

In any system with a network, something is always failing: a slow database, a partner API that's down, a server being replaced. Reliable systems expect it:

How architecture usually evolves#

Monolith ──▶ Modular monolith ──▶ + cache, queues, read replicas ──▶ extract a few services where teams or load demand it

Change the architecture when a real problem demands it: a measured performance limit, teams blocking each other, or a part of the system with very different scaling needs. Don't change it because a larger company works that way.

Checklist#

• Start with a modular monolith and clear module boundaries
• Keep application servers stateless so they can scale horizontally
• Put a timeout on every network call
• Only retry idempotent operations, with backoff and jitter
• Measure before scaling: fix queries, then cache, then replicas
• Design each feature to degrade gracefully when a dependency fails