This free visual tool helps you plan, document, and communicate software system architectures. Pick one of five pattern templates — Monolith, Microservices, Event-Driven, Serverless, or JAMstack — to instantly load a realistic starting architecture. Then customize it: add or remove components from a palette of 12 types, assign real technology names, write descriptions, and draw connections between components. When you're done, export a structured Architecture Doc for stakeholders or a Mermaid flowchart diagram you can paste directly into GitHub, Notion, or the Mermaid Live Editor.
Monolith: A single-deployable-unit architecture with Next.js frontend, Node.js/Express backend, and PostgreSQL database. The right starting point for most new products — simpler to build, test, and deploy before scale demands separation.
Microservices: A fully decomposed service mesh — React frontend, Kong API Gateway routing to Keycloak Auth Service, Node.js User Service, and Go Order Service, each with its own dedicated PostgreSQL database. Shows the database-per-service pattern.
Event-Driven: A producer/consumer pipeline — Node.js Producer publishes events to Apache Kafka, a Node.js Consumer processes them and writes to MongoDB. Models asynchronous decoupling for high-throughput workflows.
Serverless: A pay-per-invocation stack — Cloudflare CDN → Next.js on Vercel → AWS Lambda functions → PlanetScale database + AWS S3 storage. No servers to manage, scales to zero.
JAMstack: A static-first architecture — Netlify CDN serving a Gatsby frontend that pulls from Contentful CMS and Stripe for payments. Pre-rendered HTML at the edge, dynamic features via third-party APIs.
🖥️ Frontend — UI layer; browsers, mobile apps, or server-rendered pages. 🔀 API Gateway — Single entry point that routes, authenticates, and rate-limits requests to downstream services. ⚙️ Backend Service — Business logic service; can be a monolith, microservice, or serverless function. 🔑 Auth Service — Handles authentication, authorization, JWT issuance, and SSO (e.g. Keycloak, Auth0). 🗄️ Database — Persistent data store; relational (PostgreSQL, MySQL) or document (MongoDB). ⚡ Cache — In-memory layer for reducing database load and latency (Redis, Memcached, Varnish). 📨 Message Queue — Asynchronous event broker for decoupling producers and consumers (Kafka, RabbitMQ, SQS). 🌐 CDN — Global content delivery network for static assets and edge caching (Cloudflare, Fastly, Netlify). 📦 Storage — Object storage for files, media, and backups (AWS S3, GCS, Cloudflare R2). 📊 Monitoring — Observability platform for metrics, logs, and tracing (Datadog, Grafana, New Relic). 🔌 External API — Third-party service integration (Stripe, Twilio, Contentful, SendGrid). ⚖️ Load Balancer — Distributes traffic across service instances for high availability and horizontal scaling.
Select any component to open its Properties panel on the right. The 'Connects to' section shows checkboxes for every other component on the canvas — check one to draw a directional connection. Connections appear as arrows on each component card ('→ Component Name') and flow through to both export formats.
Connections represent the primary data or request flow between components. For bidirectional communication, you can draw connections in both directions by selecting each component and checking the other. The Mermaid export renders connections as arrows (-->) in the generated flowchart, making the data flow immediately visible when the diagram is rendered.
Architecture Doc: A plain-text structured document containing a Component Inventory (number, name, type, technology, description for each component) and a Connection Map (source → target pairs). Ready to paste into a Confluence page, Notion doc, README, or architecture decision record (ADR). Copy with the 'Copy Architecture Doc' button.
Mermaid Diagram: Valid Mermaid graph LR syntax with labeled nodes (component name + technology on two lines) and arrows for each connection. Paste into mermaid.live to render instantly and export as SVG or PNG. Embed in GitHub Markdown using a ```mermaid code fence — GitHub renders it natively. Also works in GitLab, Notion, HackMD, and most modern documentation tools. Copy with the 'Copy Mermaid Diagram' button.
Start with a monolith. The microservices pattern is widely misapplied — it solves scaling and team autonomy problems that most products don't have yet. A well-structured monolith (clear module boundaries, no circular dependencies, a single database with proper schema design) is faster to build, easier to debug, and simpler to deploy. You can extract services later when you hit a concrete bottleneck: a specific component needs to scale independently, teams are blocked by each other in the same codebase, or a service needs a different runtime or language. The Microservices template in this tool is a useful reference for what a decomposed architecture looks like — not a prescription to build that way from day one.
Use the actual tool or product name, optionally with a version — the same way you'd write it in a tech stack decision document. Examples: "PostgreSQL 16", "Redis 7 (Upstash)", "Apache Kafka 3.6", "Next.js 15 (Vercel)", "AWS Lambda (Node.js 20)", "Kong Gateway OSS 3.5", "Keycloak 24", "Cloudflare CDN". Including the version or hosting provider gives reviewers full context about what's actually running. If a component has not been decided yet, leave it blank or write "TBD" — the tech badge is optional.
Use the two export buttons. "Copy Architecture Doc" produces a plain-text component inventory and connection map that you can paste into any document (Notion, Confluence, Google Docs, README). "Copy Mermaid Diagram" produces Mermaid flowchart code you can share in GitHub pull requests (paste in a ```mermaid fence and GitHub renders it inline), embed in Notion (Mermaid block), or view and export as SVG/PNG at mermaid.live. For live collaboration, open the tool in separate browser tabs — each person's state is local to their tab. For persistent sharing, export the architecture doc text and store it in your repo as an ADR (architecture decision record) in /docs.
Yes — this is a practical use case. Load a pattern template that matches the system type you're studying (e.g. Microservices for a large-scale service like Twitter or Uber), then customize the component names and technologies to match the specific design challenge. Use the Properties panel to write descriptions explaining why each component exists and what it does. The Connection Map forces you to articulate data flow explicitly. Export the Mermaid diagram to visualize the final design. Working through the five templates and understanding the trade-offs between them is excellent preparation for the "Design YouTube" or "Design a ride-sharing backend" categories of system design questions.
Add an API gateway when you have more than one backend service and want a single entry point for clients, or when you need cross-cutting concerns (authentication enforcement, rate limiting, request logging) applied consistently across all services without duplicating that logic in each one. In a monolith architecture, an API gateway is typically not needed — the monolith handles routing internally. In a microservices or serverless architecture, a gateway (Kong, AWS API Gateway, Nginx, Traefik) becomes the logical place to handle SSL termination, JWT validation, and traffic routing. Avoid adding a gateway too early — it is an additional network hop and an additional system to deploy and monitor.