Service-Based Architecture: A Few Coarse-Grained Services

Objectives

By the end of the lesson, you can explain what service-based architecture is, how it differs from microservices, and why it is often regarded as the pragmatic intermediate step between the monolith and microservices.

Why is it needed?

Microservices give strong independence, but at a high price (3.3). The monolith is cheap, but it lives in a single unit (2.1). Between the two extremes there is a practical category: a few services with large areas of responsibility, which can be released separately, but are not fragmented too much.

What is it?

Service-based architecture is a distributed style in which a separately deployed user interface stands in front of a few separately deployed, coarse-grained domain services, and the services typically use a shared database. According to the summary of Mark Richards and Neal Ford's book (Fundamentals of Software Architecture, chapter 13), this style is a hybrid of microservices, with less complexity and cost than microservices or event-driven designs; the number of services is typically between 4 and 12, about 7 on average.

flowchart TB
  UI["User interface"] --> S1["Domain service 1"]
  UI --> S2["Domain service 2"]
  UI --> S3["Domain service 3"]
  S1 --> DB[("Shared database")]
  S2 --> DB
  S3 --> DB

How does it differ from microservices?

Aspect	Service-based	Microservices
Number of services	Few	Many
Granularity	Coarse, domain level	One business capability
Data	Often a shared database	Data per service
Transaction	A local transaction is possible in the shared database	Distributed transaction or saga
Operations	Fewer moving parts	Many services, many releases

The shared database is a key difference: in Ford's formulation, splitting a large database schema is one of the hardest steps of moving to microservices. Service-based style avoids it.

By aspect

Aspect	Service-based
Coupling	Smaller between services, but shared data brings data-model-level coupling
Deployability	Separate per service, with few units
Scaling	Per service, coarse-grained
Data management	Shared database: simple, but couples
Consistency	A local transaction is possible on the shared data
Failure handling	There are network calls, but few
Cost	Medium: more than the monolith, less than microservices

The price of the shared database is data coupling and weaker testability: changing the schema affects several services.

Common misconceptions

Statement	Clarification
"Service-based is a set of small microservices."	A few coarse services, typically with shared data.
"A shared database is always a mistake."	A conscious trade-off: simpler, but it brings data coupling.
"If there are services, deployability comes by itself."	A shared schema change may also require coordinated release of several services.

In short

• Service-based style consists of a few coarse-grained, separately deployed domain services.
• The services typically use a shared database.
• It brings less complexity than microservices but leaves strong data coupling.
• A common intermediate station when splitting a monolith.

Review questions

1. How does service-based differ from microservices in the number of services and in data?
2. What advantage and what risk does the shared database mean?
3. When is the service-based style enough for a system?

Learning resources

• Service-Based Architecture (Fundamentals of Software Architecture, chapter 13, O'Reilly) — the definition of the style; we saw only the preview.
• Service-based architecture (InfoQ, 2016) — summary of Neal Ford's talk: the shared database as a distinguishing feature and the goal of moving from a monolith (we refer to it based on the search result only and did not read it through).
• Comparing Service-based Architectures (Neal Ford) — comparison of SOA, service-based and microservices (we refer to it based on the search result only, we did not read it).