Choosing the right architecture for a product that must scale

Most scaling problems are organizational before they are technical. This post walks through the decision framework we apply on every engagement.

Start with the team, not the diagram A service boundary you cannot staff is a liability. Below ~15 engineers, a modular monolith with enforced module boundaries almost always wins: one deployable, one database with clear schema ownership, and module-level APIs that can later become network APIs.

The extraction test Before extracting a service ask: does it have independent scaling needs, an independent release cadence, or an independent failure domain? If none apply, extraction adds latency and operational cost for nothing.

What we actually do We ship modular monoliths with clean architecture (domain, application, infrastructure layers), event-driven seams via a message queue, and observability from day one. When a module earns extraction, the seam already exists.

Takeaway Architecture is a sequence of reversible decisions. Optimize for the ability to change your mind cheaply.