Microservices Architecture — Reladraw template

微服务拆分. Copy the source, paste into the official playground, done. No coordinates — every position is stated relative to something else.

Preview

API Gateway users-svc orders-svc payments-svc Kafka users-db orders-db

Source (.reladraw)

node gw "API Gateway"
node users "users-svc"  below-left of gw
node orders "orders-svc"  below gw
node pay "payments-svc"  below-right of gw
node bus "Kafka"  below orders
node db1 "users-db"  below users
node db2 "orders-db"  below pay
edge gw -> users
edge gw -> orders
edge gw -> pay
edge users -> bus  from: bottom
edge orders -> bus  from: bottom
edge pay -> bus  from: bottom

How to use

  1. Open the Reladraw playground
  2. Paste the source above — the diagram re-solves live
  3. Export SVG from the playground, or render locally: npx reladraw microservices.reladraw -o out.svg

When to use this template

The microservices diagram everyone actually needs: three services behind one gateway, talking through a message bus, each with its own store. Use it in design docs and system-interview whiteboards — it shows service boundaries and async decoupling in one picture.

How to customize

  1. Add a fourth service. Place it against the bus: node notify "notify-svc" below bus, wire edge gw -> notify and edge notify -> bus from: bottom.
  2. Show sync vs async. Label edges: edge orders -> bus "async" and keep gateway edges unlabeled — reviewers read the difference instantly.
  3. Split the database. Swap the single db for two: node ordersdb "orders-db" below orders and point the service edge at it directly.

FAQ

How do you diagram microservices communication?

Draw an edge for every communication path and label the ones that matter: sync calls can stay unlabeled, while queue or bus traffic gets an async label. The template here shows gateway fan-in plus a shared Kafka bus.

Should each microservice get its own database box?

Usually yes — database-per-service is the pattern reviewers check for. If two services share a store, draw both edges to the same db node; that shared box becomes an instant talking point in design review.

How is this different from a sequence diagram?

This is a static topology: who exists and who talks to whom. A sequence diagram shows the order of calls over time. Use this template for architecture docs, and the API sequence template for request flows.

About this page

Maintained by the Reladraw Templates gallery — an independent, free community resource. Sources are verified against the official Reladraw repository before publishing. Found an issue? Report it and it gets fixed.

Event-driven variant

Adds a BFF in front of the services and moves notifications onto Kafka with a webhook consumer — the shape most teams actually grow into.

Mobile Web BFF auth-svc shop-svc noti-svc Redis Kafka webhook-svc 
node users "Mobile / Web"
node bff "BFF"  below users
node auth "auth-svc"  below-left of bff
node shop "shop-svc"  below bff
node noti "noti-svc"  below-right of bff
node redis "Redis"  below shop
node kafka "Kafka"  below noti  level with redis
node wh "webhook-svc"  below kafka
edge users -> bff
edge bff -> auth
edge bff -> shop
edge bff -> noti
edge shop -> redis  from: bottom  to: top
edge noti -> kafka  from: bottom
edge kafka -> wh

Reladraw vs Graphviz for microservice maps

Graphviz (dot) is the classic choice and its layered solver is genuinely good. The difference is authoring model: Graphviz decides ranks from edge direction, so “Kafka at the bottom row, aligned” is a rank trick you have to look up. In Reladraw it is two words — below noti level with redis — right in the line. For service maps you redraw weekly with the team, statements beat solver hints.

Related templates

API Call SequenceOrg ChartMind Map