Two architectures, two project profiles
We design and build backends on microservices when the business justifies it and on a modular monolith when that is the right answer. The choice shapes three years of operational cost, team velocity, and accumulated technical debt.
In 2026 the pendulum has moved. The default narrative in many technical decisions is still "let's go microservices", but the projects that have delivered the most for our clients have leaned, more often than acknowledged, on a well-designed modular monolith. This is the decision matrix we apply.
The modular monolith in one sentence
A single application, deployed as a single artifact, divided internally into modules with explicit boundaries. Each module exposes an internal API; no module touches another module's state without going through that API. The database can be single, with per-module schemas, or segmented with one schema per module inside the same engine.
Typical stack in our projects: Spring Boot 4 modular · Quarkus with internal layers · hexagonal architecture with packages per bounded context · PostgreSQL with separate schemas · internal REST API between modules · single deploy.
Microservices in one sentence
Multiple independent services, each with its own deployable artifact, its own database, and its own release cycle. Inter-service communication goes through HTTP, gRPC, or a message bus. Each service scales, updates, and fails on its own.
Typical stack: Spring Boot / Quarkus per service · API Gateway · Kafka or RabbitMQ · PostgreSQL per service · Kubernetes · service mesh · consolidated observability with OpenTelemetry and Grafana.
Dimension 1: team size and maturity
The operating rule is clear: if the team doesn't reach eight active backend engineers, the modular monolith is the default.
Microservices introduce operational overhead inversely proportional to team size. Each additional service consumes cycles on infrastructure, pipelines, observability, version management, and inter-service debugging. For a team of four engineers, three services produce more friction than a well-modulated application of two hundred thousand lines.
When the team grows above twelve engineers, microservices facilitate division by teams. That's the operational boundary, not the two-hundred-thousand-user one.
Dimension 2: business domain cohesion
Microservices deliver value when business bounded contexts are well separated — commercial, financial, logistics, and operational teams talk about different things, evolve at different rhythms, and have independent release cycles.
When the domain is highly interconnected — most business operations cross three or four central entities — a microservice ends up being a thin wrapper around an entity, with the real logic scattered in orchestrators and distributed compensations. That pattern is a symptom of badly cut microservices, not of well-implemented microservices.
In B2B product catalogs, complex order management, and small financial domains, the modular monolith usually models the domain with less friction than three artificially separated microservices.
Dimension 3: deployment frequency and isolation
Microservices win when different parts of the system need independent release. One team deploys their service five times a day; another team deploys theirs once a week; no deployment affects the other.
In a well-built modular monolith, deployments are single and risk is controlled with feature flags, canary releases, and automated tests. When the team deploys two or three times a day and changes affect several modules at once, this works better than coordinating distributed versions.
Practical boundary: when there are parallel teams with radically different release schedules, microservices. When the business pushes the entire system at once, monolith.
Dimension 4: real need for independent scaling
Each microservice can scale on its own. When one part of the system receives ten times the traffic of the rest — usually catalog reads, search, data ingestion —, microservices allow dimensioning exactly that piece.
In practice, most medium B2B applications don't need independent scaling. The modular monolith scales horizontally with identical replicas behind a load balancer, and that solves 95% of cases below one thousand RPS. Above, microservices begin to justify themselves — provided the domain follows along.
Dimension 5: capacity to operate distributed systems
The most underestimated piece. Microservices require distributed operation: distributed tracing, idempotency on every operation, compensation when an inter-service call fails, retries with backoff, circuit breakers, API contract version management.
Teams without prior experience in these patterns reach the sixth month with a system that fails in strange ways and a dashboard nobody can interpret. The learning curve is real and gets paid in production incidents.
The modular monolith has simpler operations: one system, one database, one centralized log. Operational complexity grows linearly with functionality, not multiplicatively with the number of services.
When each architecture
Actionable summary:
| Project indicator | Recommended architecture | |-------------------|--------------------------| | Team of 1 to 8 engineers | Modular monolith | | Team of 12+ with clear bounded contexts | Microservices | | Highly interconnected domain | Modular monolith | | Naturally separated bounded contexts | Microservices | | Coordinated deployments, single team | Modular monolith | | Radically different release cycles per team | Microservices | | Load below 1k RPS without asymmetric peaks | Modular monolith | | Load with 10× asymmetry between system parts | Microservices | | Team without prior experience in distributed systems | Modular monolith |
Three real projects, three different paths
Industrial B2B distributor with 45,000 SKUs → modular monolith. Team of five backend engineers, strongly interconnected domain (catalog, pricing, orders, contracts), moderate traffic volume. Spring Boot with five bounded contexts in separate packages, PostgreSQL with five schemas. Result at eighteen months: p95 of 142 ms on critical endpoints, daily deployments without inter-team coordination, low technical debt measured with SonarQube.
Media platform with massive ingestion → well-bounded microservices. Team of fifteen engineers split into four squads, 12× traffic asymmetry between the ingestion module and the rest of the system. Quarkus for ingestion (fast startup, native), Spring Boot for the core, Kafka as the bus. Result: 2.4k sustained RPS on ingestion without affecting the rest, independent release cycles per squad, consolidated observability.
Mid-sized e-commerce that migrated from microservices to modular monolith. Less-told case. Client that had started with six microservices on a team of four engineers. By month fourteen, two engineers were going to coordinate deployments every release. Refactor to a Symfony modular monolith with clean bounded contexts. Result: coordination time dropped from three hours weekly to thirty minutes, production errors dropped 60%, team recovered feature-delivery velocity.
The intermediate pattern: modules with extraction potential
The best architectural decision we've made on long projects is building a modular monolith designed for extraction. Each module has its internal API, its separate database schema, its isolated tests. The day a module justifies its own release cycle, it gets extracted as a microservice without rewriting it — because it was already designed as one, inside the monolith.
This pattern captures the best of both worlds: simple operations today, optionality for tomorrow. It's what we call strangler-ready architecture.
How we decide with the client
Every architecture decision starts by understanding the business before the stack: how many teams there are today and three years from now, what bounded contexts actually exist, which parts of the system receive uneven traffic, what prior experience the team has in distributed systems. On top of that map we cross the five dimensions and deliver the recommendation with verifiable data.
Every decision leaves a trace in an architecture document the committee can read, contrast and, if necessary, reject with arguments. The architecture is executable from the first commit.
Behind every choice is a team of engineers who believe serious engineering starts by understanding what problem is being solved, not by picking the trend of the month. Microservices when they contribute, modular monolith when that is the right answer. Systems ready for production, not architecture demos.
If you're evaluating an architecture change or starting a new project and want a defensible decision before committing budget, we can audit your case and hand you the cross-matrix with your data before the decision gets signed.
