Microservices Architecture Diagram with Events
A microservices architecture splits one application into small services that are built, deployed and scaled on their own. Each service owns one business capability and the data behind it. Clients do not call dozens of services directly: they go through an API gateway, and services that need to react to each other's work pass events through a message broker.
This template draws the minimum that makes the style work, without naming any cloud or product: a gateway in front, three services, a database for each service that keeps data, a broker for asynchronous events, and observability that collects what every service reports. Rename the boxes to your own domain and add services as you need them.
Scroll sideways to see the whole diagram
Start from this diagram and edit it on your own board.
By continuing, you agree to the Terms of Service and Privacy Policy, including sending images of your strokes, diagram labels and similar data to providers in the United States (Cloudflare, Inc. and TypeSafe AI, Inc.) for AI conversion.
What each part does
- Client
- A browser, a mobile app or another system. It knows one address, the gateway, and nothing about how many services stand behind it.
- API gateway
- The single entry point. It routes each request to the service that owns the path, and it is the natural place for checks that every request needs, such as authentication and rate limiting. Keep business rules out of it, or it becomes a service of its own that everyone has to change.
- Orders service
- Owns orders. It answers requests from the gateway, saves the order in its own database, and publishes an event such as OrderPlaced to the broker instead of calling the other services one by one.
- Inventory service
- Owns stock levels. It serves its own requests from the gateway and subscribes to order events so that it can reserve stock when an order is placed.
- Notification service
- Reacts to events by sending email or push messages. It has no public API in this diagram and keeps no data of its own, so it has no database box.
- Orders DB
- The database that only the Orders service reads and writes. Other services get at orders through its API or its events, never by querying this database.
- Inventory DB
- The database that only the Inventory service uses. Because it is separate, the team can change its schema, or even its database engine, without coordinating with the Orders team.
- Message broker
- Holds events between the service that publishes them and the services that consume them, so the publisher does not wait for them or even know them. Many brokers deliver a message at least once, so a consumer should cope with seeing the same event twice.
- Observability
- Where logs, metrics and traces from every service arrive. With one request crossing several services, you need all three in one place to see where it was slow or failed.
How an order moves through the system
- The client sends an HTTPS request, such as creating an order, to the API gateway.
- The gateway checks the request and routes it by path: /orders goes to the Orders service and /inventory to the Inventory service.
- The Orders service validates the order and saves it in the Orders DB.
- It then publishes an OrderPlaced event to the message broker and answers the client without waiting for anything else.
- The broker delivers the event to each subscriber: the Inventory service reserves stock in the Inventory DB, and the Notification service sends a confirmation.
- Every service writes logs, metrics and traces to observability. A trace id passed along with the request, for example in the W3C traceparent header, lets you follow one request across services.
When to use it
- Planning how to split an existing application into services and deciding which data each service owns.
- Explaining why an action returns before every side effect has finished, for example why the confirmation email arrives a moment after the order.
- A design review that asks who may read which database and what happens when the broker is slow.
Common variations
Add a synchronous call between services
When a service needs an answer right now, such as a price check, draw an arrow straight to the other service. Keep these calls few, because a chain of them makes the slowest service the speed limit of the whole request.
Add a dead-letter queue
Give the broker a second box for messages that a consumer keeps failing to process, so one bad message does not block the others, and add an alert on it.
Share data by events, not by joins
If the Orders service needs a customer name, keep a small copy that is updated from events, instead of reading another service's database. Draw the event and the copy.
Split read and write paths
A busy read path can have its own service and database, filled from events. This is often called CQRS, and it is worth the extra boxes only where reads and writes really differ.
Add authentication
Put an identity provider next to the gateway. The OAuth 2.0 sequence template shows how the client gets a token that the gateway can check.
Make it yours
Rename the three services after your own business capabilities, and delete the one you do not need yet before adding more.
Opens this diagram as a board you can edit.
By continuing, you agree to the Terms of Service and Privacy Policy, including sending images of your strokes, diagram labels and similar data to providers in the United States (Cloudflare, Inc. and TypeSafe AI, Inc.) for AI conversion.