Microservices Don’t Fix Bad Architecture—They Multiply It

A badly structured monolith is difficult to maintain. Split it into twelve services and you now have the same confusion spread across databases, APIs, containers and network calls — with latency and partial failure as a bonus.

Microservices only work when the boundaries make sense. Distribution is a tax you pay for independence. If you have not earned that independence with clear ownership, you are just buying a more expensive mess.

Boundaries before distribution

Clear ownership first. Then APIs and events — never shared tables.

✓ Recommended

Clients · Mobile · WebAPI Gateway · Auth · Routing

Orders

Owns

Cart, checkout, order lifecycle

orders_db

Payments

Owns

Charges, refunds, payment status

payments_db

Inventory

Owns

Stock levels, reservations

inventory_db

Event bus · Defined APIs · Contracts

Publish events. Call public contracts. Never reach into another service's database — that's how a distributed monolith is born.

vs. the trap

✗ Distributed monolith

Many deployables, one shared brain

Orders

Payments

Inventory

shared_db

Cross-service joins · coupled deploys · tangled ownership

Clear ownership beats more services. Split when boundaries force it — not before.

Each service should represent a clear business area and own its own data. Orders should not reach directly into the payments database, and payments should not depend on the internal structure of inventory. Services communicate through defined APIs or events — not shared tables and hidden dependencies.

Once services are distributed, failure becomes normal. Calls time out, messages arrive twice and one unavailable service can affect several others. The architecture has to expect that — not hope it away.

12 practices that make microservices actually work

These aren’t rules to apply blindly on day one. They are the practices I reach for when a system needs to be split — and I only add each one when the pain it removes is real. Start with ownership. Earn the rest.

12 practices

01
Database per Service
Gives each service its own database. No shared tables, no cross-service joins — talk through APIs or events instead.
02
Bounded Context
Splits one large domain into clear business areas. Inside a service, a word like “customer” should mean one thing — not five.
03
CI/CD Pipeline
Builds, tests and deploys every service automatically and independently. Manual release steps quietly kill the model.
04
Circuit Breaker
Stops calling a failing service so one outage does not cascade. Fail fast, recover later — don’t retry forever.
05
API Gateway
Routes client requests to the right service, handles cross-cutting concerns like auth, and hides the internal map.
06
Observability
Collects logs, metrics and traces from every service. Without them, one broken request across four hops is guesswork.
07
Event-Driven Architecture
Lets services communicate by publishing and consuming events — looser coupling and room to change without a chain reaction.
08
Saga Pattern
Coordinates distributed transactions and rolls back completed steps safely when something fails halfway through.
09
Containerisation
Packages each service with its dependencies so it runs the same on a laptop, a CI runner and production.
10
Stateless Services
Stores session and cache state outside the instance. Any replica can serve any request — restarts stay boring.
11
Contract Testing
Checks that APIs stay compatible across services before either side ships a breaking change.
12
Service Discovery
Finds healthy service instances automatically at runtime — no hard-coded addresses that break on every scale event.

Ownership and boundaries first. Everything else is a tool that only helps once those are clear.

Visual overview of twelve microservices practices — A map of the practices — useful only after ownership and boundaries are clear.

How the pieces fit together

Think of the practices in layers. Boundaries and a database per service decide what can change independently. An API gateway and service discovery make those pieces reachable. Events and sagas keep workflows moving when a direct call would couple teams too tightly. Observability and contract tests keep the system honest after it ships.

If two services always deploy together, merge the boundary or rethink the contract.
If you need another team’s database to answer a question, you need an API or an event — not a join.
If you cannot trace a request across services in under a minute, observability is unfinished work.
If a timeout in payments takes down checkout UI forever, you are missing a circuit breaker (and a fallback story).

Finally, every service needs automated delivery. CI/CD pipelines should build, test and deploy changes independently, while contract tests make sure one service does not silently break another. Containers and stateless instances make those deploys replaceable instead of precious.

“Microservices are not automatically more scalable or maintainable. They earn those benefits only when ownership is clear, communication is controlled and failure has been designed for from the beginning.”

12 practices that make microservices actually work

12 practices

01
Database per Service
Gives each service its own database. No shared tables, no cross-service joins — talk through APIs or events instead.
02
Bounded Context
Splits one large domain into clear business areas. Inside a service, a word like “customer” should mean one thing — not five.
03
CI/CD Pipeline
Builds, tests and deploys every service automatically and independently. Manual release steps quietly kill the model.
04
Circuit Breaker
Stops calling a failing service so one outage does not cascade. Fail fast, recover later — don’t retry forever.
05
API Gateway
Routes client requests to the right service, handles cross-cutting concerns like auth, and hides the internal map.
06
Observability
Collects logs, metrics and traces from every service. Without them, one broken request across four hops is guesswork.
07
Event-Driven Architecture
Lets services communicate by publishing and consuming events — looser coupling and room to change without a chain reaction.
08
Saga Pattern
Coordinates distributed transactions and rolls back completed steps safely when something fails halfway through.
09
Containerisation
Packages each service with its dependencies so it runs the same on a laptop, a CI runner and production.
10
Stateless Services
Stores session and cache state outside the instance. Any replica can serve any request — restarts stay boring.
11
Contract Testing
Checks that APIs stay compatible across services before either side ships a breaking change.
12
Service Discovery
Finds healthy service instances automatically at runtime — no hard-coded addresses that break on every scale event.

Ownership and boundaries first. Everything else is a tool that only helps once those are clear.

A map of the practices — useful only after ownership and boundaries are clear.

How the pieces fit together

If two services always deploy together, merge the boundary or rethink the contract.

If you need another team’s database to answer a question, you need an API or an event — not a join.

If you cannot trace a request across services in under a minute, observability is unfinished work.

If a timeout in payments takes down checkout UI forever, you are missing a circuit breaker (and a fallback story).

“Microservices are not automatically more scalable or maintainable. They earn those benefits only when ownership is clear, communication is controlled and failure has been designed for from the beginning.”

Microservices Don’t Fix Bad Architecture—They Multiply It

12 practices that make microservices actually work

How the pieces fit together

More insights

Microservices Don’t Fix Bad Architecture—They Multiply It

12 practices that make microservices actually work

How the pieces fit together

More insights