Software architecture · Level 3: Architecture styles · Module 13 of 46

Service-based and SOA

Between the monolith and microservices sits a style that's often overlooked and frequently the right answer: service-based architecture, a handful of coarse services, each owning a whole business area, often sharing one database. It's also worth knowing its ancestor, service-oriented architecture (SOA), and why the enterprise-wide version of it failed: maximising reuse turned out to maximise coupling.

See it builtThe Architecture styles track builds this style for one bike-share app, with code you can run: 07 Service-based and SOA.

1. The idea

A hospital with a few large departments: emergency, surgery, outpatients, pharmacy. Each is a building of its own with its own staff and opening hours, so the pharmacy can be renovated while emergency stays open. They share one patient records system, which keeps things simple, and also means a records outage affects every department. That's service-based architecture: a few big, independent units over shared data.

Service-based architecture

4 to about 12 domain services, each covering a whole business area (order placement, fulfilment, billing), not one small function.
Each deployed separately, so each can be released, scaled (modestly) and fail on its own.
Usually one shared database, logically partitioned by domain. A whole workflow runs inside one service, so it can use an ordinary ACID transaction: no sagas.
Services rarely call each other. A UI (one, or one per domain) calls them, optionally through an API layer.

Orchestration-driven SOA, and how it differs

Classic enterprise SOA (popular in the 2000s) split the enterprise into layers of services: business services (place order), enterprise services meant to be reused by everything (customer, product, pricing), and an enterprise service bus (ESB) or orchestration engine that coordinates them, transforms messages and routes calls. The goal was maximum reuse. The result was that every business service depended on shared enterprise services through a central bus, so almost every change rippled across teams.

	Service-based	Orchestrated SOA	Microservices (Module 16)
Service size	Coarse: a business area	Mixed layers of shared services	Fine: one bounded context
Data	Usually one shared database	Shared enterprise databases	A database per service
Goal	Pragmatic independence	Reuse across the enterprise	Maximum independence
Coordination	Inside each service	Central bus or orchestrator	Choreography or a small orchestrator per workflow

How they rate

Characteristic	Service-based	Orchestrated SOA
Partitioning	domain	technical
Quanta	1 to many	1
Cost	★★★★★	★★★★★
Simplicity	★★★★★	★★★★★
Scalability	★★★★★	★★★★★
Elasticity	★★★★★	★★★★★
Fault tolerance	★★★★★	★★★★★
Evolvability	★★★★★	★★★★★
Deployability	★★★★★	★★★★★
Testability	★★★★★	★★★★★
Performance	★★★★★	★★★★★

Our qualitative ratings, 1 to 5 stars, more is better (for cost, more stars = cheaper). They compare styles in general; your context can move any of them.

2. How it works

Service-based: one workflow, one service, one transaction

Orchestrated SOA: reuse becomes coupling

The same shop, built the enterprise-SOA way. Watch what one small change to a shared enterprise service sets off.

3. Try it yourself

Changing a shared database

Four services share one database. Each table belongs to one domain, but some are read by other services too. Choose a table to change and how the database code is organised, and see who has to redeploy.

4. Trade-offs

Shared database vs independence

One database keeps ACID transactions, reporting and joins simple. It also means schema changes need coordination and the database is a shared bottleneck and single point of failure.

Coarse vs fine services

Coarse services keep workflows and transactions inside one deployment, and avoid chatty calls. They also mean bigger codebases per service and coarser scaling.

Reuse vs coupling

SOA's lesson: everything shared is something everyone depends on. Reuse stable, generic things; duplicate small business details rather than share them across domains.

A bus for integration vs for architecture

An ESB or integration hub is still useful for connecting packaged and legacy systems with different protocols. As the backbone of your own application's logic, it becomes a central bottleneck owned by one team.

5. In real projects

Service-based is a common landing spot when breaking up a monolith. Splitting a monolith into five domain services, still on its database, delivers most of the deployability and fault-isolation benefit for a fraction of the cost of microservices. Some teams stop there for good.

Manage the shared database deliberately. Partition the schema logically by domain, give each domain its own entity library (or let only the owner touch its tables), and run schema changes through a lightweight review so the owners of every reading service know in advance.

Is SOA dead? The enterprise-wide, reuse-everything, ESB-centred version largely is. Its ideas survive: services with contracts, integration hubs for packaged systems, and API gateways that do some of what the bus did, at the edge rather than in the middle.

Say it in the interview

Two-sentence answers

"What is service-based architecture?" A handful of coarse, separately deployed domain services, usually sharing one database. It gives independent deployment and fault isolation while keeping ACID transactions inside each service.
"Service-based vs microservices?" Service-based has fewer, bigger services and usually shared data; microservices are small, own their data and scale individually. Service-based is cheaper and simpler; microservices go further on independence and elasticity.
"Why did enterprise SOA struggle?" It maximised reuse through shared enterprise services and a central bus, so every change rippled across teams and the bus became a bottleneck. Reuse created coupling.

Red flags interviewers notice

Jumping from monolith to microservices without considering service-based.
Business logic living in an ESB's routing and transformation rules.
A shared database with no plan for who may change which tables.

6. Remember it

Memory hook: "Few big departments, one records room"Service-based: a handful of independent departments sharing one set of records. Reuse everything, and you get SOA's tangle.

How this hook works: what "few big departments, one records room" means

What the slogan means, phrase by phrase

"Few big departments": 4 to 12 coarse domain services, each deployed and run on its own.
"one records room": A shared, logically partitioned database: simple transactions, shared risk.

Why this picture fits: it carries both the benefit (departments work independently) and the catch (the records room is shared, so changes to it need care).

The story → the concept

The hospital	The architecture
Departments in separate buildings	Separately deployed domain services
A shared records room, with sections	One database, partitioned by domain
Every request routed through head office	Orchestrated SOA's central bus

The trap it saves you from

Assuming the only choices are a monolith or microservices.

7. Common mistakes

One entity library for everythingEvery schema change redeploys every service. Split it by domain, or let only the owner touch its tables.

Services calling servicesChains of calls between coarse services re-create a distributed monolith. Keep each workflow inside one service where you can.

Too many servicesTwenty-five "service-based" services sharing one database is the worst of both worlds. Keep the count small.

Logic in the busRouting rules and transformations in an ESB are hard to test and owned by one central team. Keep business rules in services.

8. Design exercise (30 minutes)

Find the departments (10 min). Split a monolith you know into 4 to 8 domain services. Write each one's workflows.
Partition the data (10 min). Assign each table to one domain. List the tables read by more than one service.
Plan a schema change (10 min). For one shared table, write how a column change would be released safely: who's told, which libraries change, which services redeploy and in what order.

9. Self-check quiz

Why can service-based architecture use ordinary ACID transactions?

Coarse services keep the whole workflow local, so no distributed transaction is needed.

How many services does a typical service-based architecture have?

Few and coarse: each owns a whole business area.

What went wrong with enterprise SOA?

Maximising reuse maximised coupling.

With one entity library per domain, a column change in the invoice table redeploys:

Splitting the library limits the blast radius to the users of that partition.

Where does an integration hub or ESB still make sense?

As an integration tool at the edges, not the backbone of an application.

10. Go deeper

Resource	Time	Why
Fundamentals of Software Architecture, 2nd edition (Richards and Ford)	book	Service-based and orchestration-driven SOA chapters, including database partitioning.
Microservices vs. Service-Oriented Architecture (Mark Richards)	short book	A focused comparison of the two styles and their trade-offs.
Service Oriented Ambiguity (Martin Fowler)	10 min	Why "SOA" meant so many different things.