Monolith-First Strategy
The monolith-first strategy advocates starting new systems as a well-structured monolith rather than diving directly into microservices. This approach recognizes that early in a product's lifecycle, the primary risk is product-market fit, not scaling. Premature microservice decomposition introduces accidental complexity — distributed transaction management, network latency, service discovery, and operational overhead — before the domain boundaries are understood.
The decision to start monolithic does not mean abandoning SOA principles. A modular monolith with clear internal boundaries, strict module dependencies, and well-defined APIs can be created from the outset. This allows teams to iterate rapidly while deferring the cost of distribution until concrete extraction patterns emerge from actual usage data rather than speculative design.
Extraction patterns follow a consistent playbook. When a module demonstrates independent scaling requirements, different release cadences, or needs to be owned by a separate team, it becomes a candidate for extraction. The strangler fig pattern is the canonical approach: place a facade in front of the monolith, route new requests for the extracted service directly, and gradually migrate existing traffic. This allows continuous delivery throughout the migration without big-bang cutovers.
Common extraction triggers include modules with divergent data access patterns, features requiring specialized infrastructure (GPU compute, exotic databases), or components that experience significantly different load profiles. For example, a notification module that scales independently from the core order processing is a prime candidate, as is a search service that benefits from dedicated Elasticsearch infrastructure.
Data extraction is the most complex aspect. The database-per-service pattern requires splitting a unified schema into bounded contexts. A practical approach is to start with logical schema separation within the same database, introduce read replicas or API-based data access for dependent services, and eventually migrate to independent databases. The expand-contract pattern for database migrations allows backward-compatible schema changes that enable gradual migration without downtime.
The monolith-first approach also mitigates the "distributed monolith" anti-pattern, where services are deployed separately but remain tightly coupled through shared databases or synchronous call chains. By forcing teams to establish clean module boundaries while still in a monolith, the eventual extraction produces genuinely independent services.
Organizational alignment is critical. Conway's Law dictates that system architecture mirrors communication structures. Teams should own modules that align with their expertise and operational responsibilities before extraction. Once extracted, each service should be owned by exactly one team with full autonomy over its deployment and data.
When to avoid monolith-first: if the system is inherently distributed (IoT data ingestion, real-time event processing) or if the organization already has mature platform infrastructure and experience operating microservices. For most products, however, the pragmatic starting point is a well-structured monolith with extraction-ready internal boundaries.