// Architecture Styles · 04
Microservices
Small services, each owning its data, deployed on their own.
How it fits together
- Mobile app uses / calls API Gateway (HTTPS)
- API Gateway uses / calls Orders service (routes)
- Orders service uses / calls Orders DB (owns)
- Orders service publishes / notifies Broker topic (OrderPlaced)
- Broker topic publishes / notifies Notifications service (subscribes)
- Notifications service uses / calls Notifications DB (owns)
Spot it
- Teams queue up behind one release train
- One hot feature needs very different scale
- Parts need different tech or release pace
It costs
In-process calls and transactions become network failures, eventual consistency and heavy ops.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
The point is independent deployability: a team can change, test and ship its service without coordinating a release. That only holds if each service owns its data and boundaries follow business capabilities, not technical layers.
Do not start here. Without several teams or real differences in scale, you pay for service discovery, tracing, contract versioning and partial failures and get little back. Services that must deploy together, a distributed monolith, are the common failure.
Boundaries come from bounded contexts; a modular monolith is the usual stepping stone, and the strangler fig is how you get there from legacy. Cross-service workflows need sagas, outboxes and idempotent consumers.
Ask for it
- database per service
- independent deployability
- API gateway
- asynchronous messaging
- distributed tracing
Extract the Notifications capability from this monolith into its own service with its own database. Callers publish events to a broker topic instead of calling it directly. Add health checks, OpenTelemetry tracing and a separate deploy pipeline.