Open the editor

Diagrams as code for microservices

Draw systems by typing.

Write services and use cases as text. Proschi draws the diagram and plays every request through it.

Open the editor 2-minute quickstart
Interview prep 25 system design problems in 8 stages
  • Free & open source
  • No account
  • Runs in your browser
checkout.proschi 
title "Checkout"

web "Web Shop" [Actor]

group vpc "AWS VPC" {
  api "Order API" [REST API]   @orders
  db  "Orders DB" [PostgreSQL] @orders
}
events "OrderEvents" [Kafka] @platform

web -> api    : HTTPS
api -> db     : SQL
api -> events : publish

usecase "Place order" {
  web -> api : POST /orders json {"sku": "A1"}

  alt "Placed" {
    api  -> db     : INSERT order
    api ->> events : OrderPlaced {"orderId": "o-1"}
    api --> web    : 201 {"orderId": "o-1"}
  } alt "DB down" {
    api  -x db  : INSERT order
    api --> web : 503 {"error": "retry_later"}
  }
}

The editor, the diagram and the player load next.

For system design interviews

Interview prep roadmap

25 system design problems in 8 stages, from a URL shortener to ride matching. Each stage builds on the one before, the way interviewers expect you to reason.

  • Lesson Explains the concepts the problem needs before you start.
  • Challenge Design it hands-on; a simulation checks load, latency, failures and cost.
  • Review Feedback on your design: what holds up and what to improve.
Start interview prep

Sign in to start; browse the stages and lessons any time.

The stages

  1. Foundations 4 problems
  2. Caching and the edge 3 problems
  3. Partitioning and replication 3 problems
  4. Queues and async work 3 problems
  5. Fan-out and real-time delivery 3 problems
  6. Streams and aggregation 3 problems
  7. Consistency and contention 3 problems
  8. Geo, media and hot spots at scale 3 problems

How it works

Three steps. The first one is typing.

  1. Write it

    Services, databases and queues: one line each. Arrows say who calls whom.

    api "Order API" [REST API]
db  "Orders DB" [PostgreSQL]

api -> db : SQL

  2. See it

    Auto layout draws the diagram as you type. No boxes to drag.

  3. Play it

    Press play. The request hops through the diagram: the happy path and every failure, step by step.

Break it on purpose.

Every alt is a way your system fails. Watch the packet die at the database, not in production. 

usecase "Pay" {
  web -> api : POST /pay

  alt "Paid" {
    api  -> db  : INSERT payment
    api --> web : 201
  } alt "DB down" {
    api  -x db  : INSERT payment
    api --> web : 503 {"error": "retry_later"}
  }
}
The “DB down” scenario: the call from the Order API to the Orders DB gets no answer, and the API replies 503. REST API Order API PostgreSQL Orders DB 503

Test your design.

Requirements, traffic and capacity, checked in your browser. Green means it holds up.

traffic {
  "Redirect" 100k rps mix "Cache hit" 90%, "Cache miss" 9%, "Unknown code" 1%
}

requirements {
  p99 "Redirect" < 100ms
  availability "Redirect" >= 99.95%
  survive any node failure
  cost <= 5000 usd/month
}

Tests URL shortener example 5 / 5 pass

  • p99 of Redirect < 100 msp99 of Redirect is 24.3 ms (limit 100 ms)
  • availability of Redirect ≥ 99.95%availability of Redirect is 99.999999% (limit 99.95%)
  • survive any node failureEvery use case keeps working after losing any of 4 nodes
  • cost ≤ $5,000/monthTotal cost is $3,000/month (limit $5,000/month)
  • Redirects are served from the cacheAll 6 assertions hold

Practice system design

25 system design problems. Tests, not opinions.

    All problems

    Examples

    Open one, break it, make it yours.

    Free. Open source. No account.

    Your diagrams never leave the browser.

    Start typing