Service-Based Architecture: A Pragmatic Middle Ground Between Monoliths and Microservices

1. What Is Service-Based Architecture?

Microservices have become ubiquitous, yet many teams adopt full microservice decomposition only to drown in service orchestration, distributed transactions, and operational overhead — costs that are disproportionate for medium-sized systems. Service-based architecture (SBA) is a hybrid variant of microservices and one of the most pragmatic architectural styles. It serves as a stepping stone toward other distributed architectures: first split the system into coarse-grained domain services, observe which domains truly need further decomposition, and then decide whether to evolve into microservices — rather than applying a one-size-fits-all approach.

2. Topology

SBA follows a distributed macro-layered structure composed of three parts:

Independently deployable user interfaces

Independently deployable remote coarse-grained services

Optional monolithic database

These services typically represent a domain or subdomain, hence called domain services . They are coarse-grained, encapsulate a relatively complete piece of functionality, are deployed independently, and their deployment model resembles that of a traditional monolithic application.

2.1 Domain Service Internals

Despite being coarse-grained, domain services have internal structure. Two common designs:

Layered architecture — each domain service is organized into an API facade layer, a business layer, and a persistence layer.

Subdomain partitioning — further divide the domain service by subdomains, similar to a modular monolith.

Regardless of the design, every domain service must expose an API facade through which the user interface interacts with the service and executes business functions; the facade orchestrates the business request.

2.2 API Gateway

An API gateway or reverse proxy can be placed between the user interface and the services. Its roles include: exposing domain service capabilities to external systems; consolidating cross-cutting concerns (metrics, security, auditing, service discovery) into the gateway; and load-balancing across multiple instances of a domain service.

2.3 Data Topology

SBA gives architects multiple database topology choices. It is the only distributed architecture that can efficiently support a monolithic database. However, that monolithic database can also be split — even to the point of assigning each domain service its own domain-level database, achieving database separation similar to microservices.

An anti-pattern to avoid: stuffing all entity objects corresponding to every database table into a single shared library . A schema change to any table then forces all services using that shared library to be modified and redeployed, even if they never touch that table.

A better approach is logical partitioning with multiple shared libraries. For example, partition the database into five domains — common, customer, invoicing, order, tracking — each with its own shared library. Changing invoicing-related tables then only affects services that use the invoicing shared library; other services remain untouched.

3. Common Risks

Excessive inter-domain service communication. In microservices, service-to-service communication is the norm; in SBA, architects should strive to minimize it. The ideal is for domains to be as independent as possible, with coupling occurring only at the database layer. Frequent communication between domain services signals either incorrect domain boundaries or that SBA is the wrong style for the problem.

Too many domain services. The practical upper limit is about 12 services . Beyond that, testing, deployment, monitoring, database connections, and change management start to break down.

4. Characteristic Scores

SBA is a domain-partitioned architecture — its structure is driven by business domains, not technical concerns. The scorecard shows no perfect scores, but four-star ratings in several key dimensions:

Maintainability, Testability, Deployability, Evolvability — splitting the application into independently deployable domain services yields faster changes, better test coverage, lower deployment risk, and shorter lead times.

Fault tolerance — services are self-contained and rarely communicate; a failure in one service does not cascade to others.

Scalability earns only three stars, elasticity only two stars because of coarse-grained services. Replicating a coarse-grained service replicates an entire functional block, making resource utilization less economical than fine-grained microservices. Typically each service runs a single instance; scaling to multiple instances occurs only when higher throughput or failover is needed.

Simplicity and overall cost are the key advantages that distinguish SBA from heavier distributed architectures (microservices, event-driven, space-based). This is why SBA is the easiest to implement and offers the best cost-effectiveness. The trade-off is clear: lower cost and complexity mean lower ceilings for scalability, elasticity, and fault tolerance.

Two especially noteworthy points:

Natural fit with Domain-Driven Design (DDD). Coarse-grained, domain-scoped services map directly to a DDD bounded context, making it easy to encapsulate functionality into an independently deployable unit for iteration.

Best among distributed architectures for ACID transactions. Because domain services are coarse-grained, transaction scope stays within a single service, allowing traditional commit/rollback semantics — a capability that is usually unattainable in other distributed architectures.

4.1 Suitable Scenarios

Medium-sized business applications that need distributed benefits but want to avoid microservice complexity.

Systems adopting DDD where each domain naturally maps to a domain service.

As a stepping stone toward microservices or other distributed architectures — split by domain first, then decide which domains need further decomposition.

Distributed scenarios requiring decent ACID transaction support.

4.2 Unsuitable Scenarios

When extreme scalability and elasticity are required — coarse-grained service replication is costly compared to microservices.

When fine-grained independent scaling of services is needed.

When the business inherently demands heavy cross-service collaboration and orchestration, violating SBA's low-communication principle; another style should be considered.

5. Team Topology

Because SBA is domain-partitioned, it best aligns with cross-functional teams organized around domains . When requirements arrive along domain lines, a domain-aligned cross-functional team can complete the work within its corresponding domain service without interfering with other teams or services. Conversely, technology-siloed teams (frontend, backend, database) clash with this architecture — a single domain requirement would require coordination across multiple technical teams, which is painful in most organizations.

Mapping to the four team topologies:

Stream-aligned teams — work well when domain boundaries align, especially when the stream focuses on a specific domain. If a stream crosses domain service boundaries, boundaries and granularity must be re-evaluated: either realign or change architecture.

Enabling teams — less effective than in other distributed architectures due to coarse-grained services. However, architects can identify and create suitable components inside each domain service to improve modularity, allowing experts to advise and experiment on those components.

Complicated-subsystem teams — can leverage domain-level and subdomain-level modularity to focus independently on complex domain or subdomain processing without interference from other members or services.

Platform teams — high modularity enables reuse of common tools, services, APIs, and tasks, yielding a good fit with the platform team topology. 1. Fundamentals of Software Architecture 2nd Edition, Chapter 14 ↩︎