InterviewKata
Software architecture · Level 3: Architecture styles · Module 16 of 46

Microservices

Microservices take distribution as far as it goes: many small services, each built around one part of the business, each owning its own data, each deployed, scaled and failing on its own. Done well, dozens of teams can change a large system independently. Done badly, it's a distributed monolith with a hundred deployment pipelines. This module covers the defining rules, how to decide how big a service should be, and the operational machinery the style can't live without.

See it builtThe Architecture styles track builds this style for one bike-share app, with code you can run: 08 Microservices.

1. The idea

A street of small specialist shops instead of one department store. The baker, the butcher and the bookshop each own their stock, their till and their opening hours, and each can renovate or expand without asking the others. They cooperate through clear interfaces (a delivery, an order slip), never by walking into each other's stockroom. The street is resilient and flexible; it also needs shared roads, rubbish collection and a way to find each shop.

How big should a service be?

"Micro" is a label, not a size. Granularity is a trade-off between forces that push a service apart and forces that pull it together:

Disintegrators: reasons to split

  • Scope: it does unrelated things.
  • Code volatility: one part changes weekly, another yearly.
  • Scalability: one part needs far more capacity.
  • Fault tolerance: one part's crashes shouldn't take the other down.
  • Security: one part handles sensitive data with stricter rules.
  • Extensibility: one part keeps gaining new variants.

Integrators: reasons to keep together

  • Transactions: a change must be atomic across the parts.
  • Workflow: they always call each other in sequence.
  • Shared code: they depend on a lot of the same logic.
  • Data relationships: their data is tightly joined.

How it rates

CharacteristicMicroservicesService-based
Partitioningdomaindomain
Quanta1 to many1 to many
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

A database per service

Orders needs the customer's name and address, which belong to the Customer service. In a monolith, that's a join. Watch the two ways microservices answer it.

Sidecars and a service mesh

Every service needs timeouts, retries, encryption and metrics. Coding them into every service, in every language, is how they drift apart. Watch them move into a sidecar.

3. Try it yourself

Should Payments be one service or three?

Payments has three parts: card payments, gift cards and refunds. Tick the facts that are true for your system and see what the forces recommend, and what each choice costs.

Reasons to split

Reasons to keep together

4. Trade-offs

Independence vs operational cost

Each service is another pipeline, set of dashboards, on-call rotation and upgrade to apply. The style pays off for large organisations with many teams; for a small team it's mostly cost.

Own data vs easy queries

A database per service frees each team to change its schema, and turns every cross-service question into an API call, an event-fed copy, or a reporting pipeline (Module 23).

Fine vs coarse services

Smaller services isolate change and scale precisely; too small, and workflows become chains of network calls and distributed transactions. Let disintegrators and integrators decide, not a line count.

Shared library vs sidecar vs duplication

Shared libraries are easy but version-couple services; sidecars handle operational concerns outside the code; duplicating small amounts of business code is often cheaper than coupling to share it.

5. In real projects

"Microservice all the things" is a pitfall. Splitting every noun into a service produces hundreds of tiny services that must all be deployed together to deliver a feature. Start coarser (service-based, Module 13) and split where a disintegrator demands it.

Know what you have. With dozens of services, a service catalogue becomes essential: for each service its owner, domain, criticality, data it holds, and contracts. Some teams add this metadata to the code itself (annotations or a manifest) so tooling can check it.

Organise teams to match. Microservices work when each team owns a few services end to end. If several teams must coordinate every release, the boundaries or the team structure are wrong (Conway's law, Module 08).

Say it in the interview

Two-sentence answers
  • "What makes something a microservice?" One bounded context, its own data, independently deployable, communicating only through APIs and events. Size follows from those, not from lines of code.
  • "How do you decide service granularity?" Weigh disintegrators (volatility, scalability, fault tolerance, security) against integrators (transactions, workflow, shared code, data relationships). Split only where a disintegrator outweighs the integrators.
  • "How does a service get another service's data?" Through its API when it needs the latest value, or from a local copy kept up to date by events when it needs speed and independence.
Red flags interviewers notice
  • Services sharing a database "for now".
  • Splitting a workflow that needs one transaction, with no saga.
  • No mention of observability, deployment automation or contracts.

6. Remember it

Memory hook: "Own your stock, use the front door"Every service owns its data; everyone else comes in through its API or listens to its events.
How this hook works: what "own your stock, use the front door" means

What the slogan means, phrase by phrase

"Own your stock"
A database per service: nobody else reads or writes it.
"use the front door"
Other services use its API or subscribe to its events, never its tables.

Why this picture fits: data ownership is the rule most often broken, and breaking it quietly turns microservices back into one quantum (Module 09).

The story → the concept

A street of shopsMicroservices
Each shop's own stockroomDatabase per service
The shop counterThe service's API
The shop's newsletterThe service's events
Roads, bins and street signsGateway, discovery, mesh, observability

The trap it saves you from

The shared database that makes a hundred services release as one.

7. Common mistakes

The distributed monolithServices that share data or call each other synchronously in long chains. All of the cost, none of the independence.
Too fine, too earlyHundreds of nanoservices before the domain is understood. Boundaries are cheap to move inside a monolith and expensive between services.
Business logic in shared librariesA shared "common" library with domain rules forces every service to upgrade in step.
Skipping the platformMicroservices without automated deployment, tracing and contracts are unmanageable at any size.

8. Design exercise (30 minutes)

  1. Pick the services (10 min). For an online shop, list 6 to 10 services by bounded context. For each, name its data.
  2. Test one split (10 min). Take one service and list its disintegrators and integrators. Would you split it?
  3. Feed the copies (10 min). For one cross-service read (orders showing customer names), design the event that keeps a local copy fresh, and how stale it may get.

9. Self-check quiz

How should Orders get a customer's address?

Data ownership keeps each service independently changeable.

Gift-card rules change weekly; card payments change yearly. Which disintegrator is this?

Different rates of change favour separate services.

A refund must reverse a card charge and a gift-card redemption atomically. Which integrator?

Splitting would need a saga with compensations (Module 24).

What does a service mesh's sidecar typically handle?

Operational concerns move out of the code into a proxy beside each service.

When do microservices pay off most?

Independence across many teams is the main benefit; for small teams it's mostly cost.

10. Go deeper

ResourceTimeWhy
Microservices (James Lewis and Martin Fowler)30 minThe article that defined the style's characteristics.
Software Architecture: The Hard Parts (Ford, Richards, Sadalage, Dehghani)bookGranularity disintegrators and integrators, data ownership and code reuse.
Microservice patterns (Chris Richardson)browseDatabase per service, API gateway, sidecar, and many more, each explained.