Architecture Diagram Builder

Place components, drag them, connect them (Connect → click source → click target; toggle “async edge” for publish/consume links). The evaluator calls out single points of failure, tight coupling, bottlenecks, data-consistency concerns, security boundaries and scaling limits — and links each to the lesson.

Presets
Add
10 components · 11 connections · 7 findings
ClientCDNLoad BalancerBackend: ×3RedisDatabaseRead ReplicaQueueWorkerExternal API: Payments

Click a connection to remove it. Dashed orange edges are asynchronous. Label compute “×3” to mark multiple instances, external APIs “breaker” once one exists.

Request latency
long chains or third parties: p99 in seconds
Complexity
distributed: tracing, contracts, on-call rotation
Single points of failure
  • Load Balancer is a single point of failure: if it dies, the client loses External API (Payments), Queue, Database, Read Replica, Redis. Run at least two instances behind a balancer, or label it "×N". lesson →
  • Redis is a single node. If the cache is on the request path, its loss must be survivable (cache-aside falls back to the DB — but a cold cache can then stampede the DB). Label it "cluster" or plan the fallback. lesson →
Potential bottlenecks
  • External API (Payments) is a third-party dependency on the request path. A slow provider holds your threads; without a timeout and a circuit breaker its outage becomes yours. Label it "breaker" once one exists. lesson →
Data consistency
  • Read replicas lag. A user who writes and immediately reads from a replica sees the old value; route read-your-own-writes to the primary or wait for the replica LSN. lesson →
  • Cache and database hold the same data twice. Decide the invalidation rule now (TTL, delete-on-write, or events), and jitter TTLs so keys do not expire together. lesson →
  • Queues deliver at least once. Every consumer must be idempotent (processed-id table or upsert) or you will double-send emails and double-decrement stock. lesson →
  • A payment provider on the path: a timeout after the charge succeeded is the classic double charge. Send an idempotency key with every charge and store the result. lesson →
What is right about it
  • Background work is decoupled from the request path: workers scale on queue depth and a slow job cannot hold a user request. lesson →
  • CDN at the edge: static and media requests never reach the origin, and users far from it get local latency. lesson →
  • Stateless instances behind a balancer: any instance can serve any request, so instances are disposable and rolling deploys work. lesson →
  • Read replica present: reads scale out and there is a failover target. lesson →
  • Asynchronous edges present: those consumers can be down without failing the request that produced the message. lesson →

How the evaluation works

Rule-based, transparent, and opinionated in favour of the simplest thing that meets the requirement.

  • Single points of failure — each non-data component is removed in turn; if the client loses reach to a data store, queue or external system and the component has no peer of the same kind (or a “×N” label), it is flagged. Databases without a replica and single-node Redis are flagged directly.
  • Tight coupling — services sharing a database, synchronous chains of four or more hops, services with three or more synchronous peers, cycles among synchronous calls, and a gateway labelled with business logic.
  • Bottlenecks — a database read by several components with neither cache nor replica, compute called directly by the client, third-party APIs on the request path without a breaker, object storage without a CDN.
  • Data consistency — multiple service-owned databases (sagas, outbox), replicas (lag), cache + database (invalidation), queues (at-least-once, idempotency), Kafka (partition-key ordering), search indexes written synchronously.
  • Security boundaries — clients reaching data stores, services or queues directly; agents with direct database or external access; no edge to rate-limit at.
  • Scaling limits — compute with no externalised state, sessions behind a balancer, one database under many compute components, workers without a queue.
  • It cannot see timeouts, retries, budgets, indexes or permissions — those live in code and configuration. Use the Failure Simulator to test what actually breaks.