Drawing clear architecture diagrams
35 min · Intermediate
An architecture diagram shows the parts of a system as boxes and how a request moves between them as arrows. In a design round it is the page everyone looks at, so a clear one makes an average design look organised, and a messy one hides even a good design.
Topics in this lesson
- Standard boxes: the parts every backend reuses
- Request flow: numbered arrows, read and write paths
- The diagram-in-words notation used in this course
- Before and after: a cluttered vs a clear diagram
- Labelling data stores and sync vs async arrows
Key points
- Use the standard boxes: client, CDN, load balancer, service, cache, database, queue, worker.
- Number the steps and draw read and write paths separately.
- Notation:
[program],[(store)],[[queue]],-->sync,..>async,(n)step. - Label stores with technology and data, keep only the request path, and put cross-cutting concerns in a note.
Interview questions this lesson answers
- What do you draw first in a design round?
- Why separate the read path and the write path?
- How do you show that something happens in the background?
- What makes a diagram cluttered?
- How do you label a database on a diagram?
- How does a diagram help you find single points of failure?
Sign in to continue this lesson
Create an account to read every lesson, practise with the exercises and keep track of your progress.