Microservices Architecture Flowchart in Mermaid

Mermaid code

flowchart LR
    subgraph Clients
        Web[Web app]
        Mobile[Mobile app]
    end
    GW[API gateway]
    subgraph Services
        Users[User service]
        Orders[Order service]
        Inventory[Inventory service]
    end
    UsersDB[(Users DB)]
    OrdersDB[(Orders DB)]
    InvDB[(Inventory DB)]
    Bus{{Message broker}}
    Web --> GW
    Mobile --> GW
    GW --> Users
    GW --> Orders
    GW --> Inventory
    Users --> UsersDB
    Orders --> OrdersDB
    Inventory --> InvDB
    Orders -- order.created --> Bus
    Bus --> Inventory

Paste this into any tool that renders Mermaid, or into the editor to change the theme and export PNG or SVG. Syntax reference: Flowchart guide.

What this diagram shows

Read it left to right. The Clients subgraph holds the web and mobile apps, both of which call a single API gateway. The gateway routes to three services, and each service owns exactly one database, drawn with the [( )] cylinder shape. The Orders service publishes an order.created event to the Message broker (hexagon), which the Inventory service consumes, so stock is reserved without a direct call between the two.

A flowchart beats a sequence diagram here because the point is topology, not timing. Subgraphs group the tiers, and the LR direction keeps request flow reading like a sentence.

How to adapt it

• Rename the three services and databases to match your domain, keeping one [( )] cylinder per service so ownership stays obvious.
• Add a fourth tier such as subgraph External for payment or email providers and connect it with dotted arrows (-.->) to mark third-party calls.
• Change flowchart LR to flowchart TD if the diagram will sit in a narrow document column.
• Replace the hexagon {{Message broker}} with a named topic per event if you publish more than two or three event types.

FAQ