Isolated third-party integration
Wrap Stripe, shipping or ERP behind a stable internal API.
What is a microservice? Definition and good practices
A microservice is an autonomous software component that implements one business capability — such as send an invoice or compute a price — and runs as a separate process. It exposes an interface (often HTTP) and owns its data or schema. Other services call it without touching its database directly.
In one sentence
A microservice is an independent business building block you can deploy and evolve without breaking everything else.
Key points
- Size follows the domain, not an arbitrary line count.
- Network communication is explicit: latency, retries and stable formats are normal.
- A mature org may dedicate a team and codebase to it.
- Not a tiny monolith: avoid shared databases between services.
Term at a glance
- Microservice
- Micro-service
- French term
- Microservice
- Domain
- Web development
- Category
- Architecture
- Level
- Intermediate
Beyond the buzzword
Micro misleads: what matters is deploy independence and clear ownership. An orders service can be thousands of lines if it stays coherent and testable alone.
Classic anti-patterns: two services reading one SQL table, deep synchronous call chains, or layering splits that recreate a distributed monolith.
For a growing SMB, a useful first microservice is often carved from the monolith — payments, document generation, email — where isolation delivers measurable gain without rewriting the product.
How to design a microservice
- 01
Name the capability
Phrase as a business verb: notify, price, sync inventory.
- 02
Encapsulate data
Only this service writes its records; others use its API.
- 03
Make the API explicit
OpenAPI or equivalent, clear errors, versioning from day one.
- 04
Plan operations
Health checks, metrics, structured logs with correlation IDs.
A concrete example
An equipment rental app keeps a monolith for bookings but extracts an availability microservice. It merges calendar and shop returns and answers search in milliseconds. When maintenance rules change, only that service redeploys — rental contracts in the monolith stay untouched.
Typical microservice roles
Heavy processing
PDF generation, image resize, video transcoding via queues.
Sensitive data
Segment PII or payments for tighter access and audits.
Experimentation
Try a recommender without risking the transactional core.
Benefits and limits
- Targeted deploy and safer rollback
- Stack fit for the job
- Clear owning team
- Smaller blast radius on failure
- Network and observability overhead
- Possible duplicated models or validation
- API governance required
- Pointless if a modular monolith suffices
Microservice or internal module?
| Microservice | Module in a monolith | |
|---|---|---|
| Deployment | Separate process or container | Same binary as the rest |
| Data | Dedicated store or private schema | Shared tables, local transactions |
| Communication | HTTP, messaging, gRPC | In-process calls |
| When to choose | Independent scale or team needed | Strong cohesion, modest load |
For leadership
Microservice in a proposal should mean a deliverable, measurable component — not a label. Each service adds operations: monitoring, patching, security. Invest when isolation removes real risk the monolith cannot absorb.
Frequently asked
Can a microservice have a UI?
Usually no — it exposes an API. UI lives in the front-end or an API gateway.
REST or async messaging?
REST for immediate request/response. Queues for spikes, retries and temporal decoupling.
One microservice per database table?
No — an anti-pattern. Split by business capability, not tables.
Related terms
Sources and references
Thinking of extracting a piece from your current application?
Assess the split