微服务拆分. Copy the source, paste into the official playground, done. No coordinates — every position is stated relative to something else.
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: bottomnpx reladraw microservices.reladraw -o out.svgThe 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.
node notify "notify-svc" below bus, wire edge gw -> notify and edge notify -> bus from: bottom.edge orders -> bus "async" and keep gateway edges unlabeled — reviewers read the difference instantly.node ordersdb "orders-db" below orders and point the service edge at it directly.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.
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.
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.