Microservices Architecture — many small services, one system
Microservices architecture on an interactive canvas: the client layer, API gateway, independently deployed services, messaging, per-service data stores and observability.
Microservices is an architecture where an application is built from many small, independently deployed services, each owning its own data, coordinated through an API gateway and messaging rather than through shared state.
Microservices Architecture — many small services, one system
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read the left column top to bottom first: clients to gateway to services — that is the request path.
- Follow the arrows out of each service: to the message bus, to its own database, and to observability.
- The right-hand bands are the system's shared infrastructure — messaging, data and observability — which is why each service points into them.
The request path
"Web and mobile clients" start the flow, and "API gateway routes and aggregates" is the single entry point — routing each request to the right service, handling authentication, and often assembling responses from several services. The gateway is the one component every client sees, which is why it sits between the client layer and the services.
The services
"Orders service", "Users service" and "Payments service" are the independently deployed units. Each is owned by its own team and ships on its own cadence. The visual connects each service to the message bus — services communicate by events rather than direct calls — and to its own database, because owning its data is what makes a service deployable independently.
The shared infrastructure
"Message bus decouples services" lets one service publish an event without knowing who consumes it. "Each service owns its own database" is the rule that prevents shared-state coupling. "Metrics, logs and traces feed one view" is the observability that makes a system of many services operationally sane — without it, a failure is invisible across the boundaries. These three bands are the price and the payoff of the architecture.
Key relationships and takeaways
- Each service is independently deployable — the property everything else in the architecture exists to protect.
- Services communicate through the message bus and own their own databases; shared state is the anti-pattern.
- The API gateway is the system's single front door; clients never talk to services directly.
- Independence must be paid for with observability — many services are only manageable when one view covers them all.
- Microservices orchestrate the containers Docker packages — the two visuals connect.
When to use this visual
- Teaching a team why microservices exist and what the trade-offs actually are before they adopt them.
- Documenting an existing system's service boundaries, message topics and data ownership for onboarding.
- Auditing for the anti-patterns: a shared database or a service calling another service directly is a boundary leak.
How it works
Rename the services to your system
Replace Orders, Users and Payments with your actual services, and add the ones the generic three miss, each as its own box in the Services band.
Name your message topics
Annotate the message bus with the real events your services publish and subscribe to, so the decoupling is concrete rather than asserted.
Map the data ownership
On each service's edge to its database, note the actual store (PostgreSQL, a cache, a search index) and what it owns, to check the one-database-per-service rule holds.
Add the failure and scaling branches
Insert the real paths — a service's retry and circuit-breaker on the bus, a scaled-out replica of a hot service — each ending in an explicit state.
Frequently asked questions
What is microservices architecture?
It is an architectural style in which an application is built from many small services, each responsible for one business capability, deployed independently and owning its own data. Services communicate over a network — typically HTTP and a message bus — rather than sharing memory or a database. The benefits are independent deployability and team autonomy; the costs are network complexity and the need for observability.
Why does each microservice own its own database?
Because shared data is the coupling that breaks independent deployment. If two services read and write the same table, they cannot change their schema, scale or deploy without coordinating. Owning its own data store is what lets a service evolve and scale on its own schedule — the rule the "Each service owns its own database" band in the visual enforces.
What is the role of the API gateway in microservices?
The gateway is the system's single entry point. It routes requests to the right service, handles cross-cutting concerns like authentication and rate limiting, and can aggregate responses from several services into one. Clients talk to the gateway, never directly to individual services, which keeps the service topology free to change behind it.
When should you NOT use microservices?
When the system is small or the team is small. Microservices trade architectural complexity — network failures, distributed transactions, observability — for independent deployability, and that trade only pays off once a team is large enough that independent deployability is the binding constraint. Many teams' problems are solved by a well-modularised monolith, which is the subject of the monolithic architecture visual.
Edit this visual in QueryChart (FlowJam)
Open this exact microservices canvas as your own chart, rename the services to your system, and map your real boundaries.