How to Draw Architecture

Standard Symbols Every Interviewer Expects

In a system design interview, your diagram is your primary communication tool. Amazon interviewers expect clean, consistent symbols. Here is the universal vocabulary:

Symbol	Represents	Example
Rectangle	Service / Microservice	User Service, Order Service, Payment Service
Cylinder	Database (persistent storage)	PostgreSQL, MySQL, DynamoDB
Diamond	Load Balancer / Decision Point	ALB, NLB, API Gateway
Rounded Rectangle	Cache	Redis, ElastiCache, Memcached
Parallelogram	External System / Third-party	Stripe API, SendGrid, S3
Cloud	External Service / Internet	AWS, CDN (CloudFront)
Arrow (solid)	Synchronous data flow (HTTP, gRPC)	REST API call, request/response
Arrow (dashed)	Asynchronous data flow (queues, events)	SQS message, Kafka event
Double-headed arrow	Bidirectional communication	WebSocket connection
Dotted line	Polling / Periodic check	Health check, cron job

Service Symbols in Detail

Rectangles (Services):

• Use a single rectangle per service
• Keep consistent sizing — all services should be roughly the same width
• If a service has sub-components, use a larger rectangle containing smaller ones (nested rectangles)
• Example: ┌─────────────────┐
│ Order Service │
└─────────────────┘

Cylinders (Databases):

• The cylinder is universally recognized for databases
• Always specify the type inside or below: PostgreSQL, DynamoDB, MongoDB
• Use separate cylinders for separate databases — do NOT put multiple DB types in one cylinder
• For replicated databases, draw one cylinder and add x3 or replicas label

Diamonds (Load Balancers):

• Diamonds represent routing decisions and load balancers
• Label with the type: L7 LB (Application Load Balancer) or L4 LB (Network Load Balancer)
• Place between clients and services, or between services and databases for read distribution

Rounded Rectangles (Caches):

• Caches sit between the application layer and the database
• Label with technology: Redis, Memcached
• Note eviction policy if relevant: LRU, TTL=5min

Drawing ASCII Symbols on Whiteboard

On a physical whiteboard or digital tool, use these ASCII patterns:

Service:    ┌──────────────┐
            │  API Gateway  │
            └──────────────┘

Database:   ╭──────────────╮
            │   DynamoDB    │
            ╰──────────────╯

Cache:      (──────────────)
            (   Redis       )
            (──────────────)

Load Bal:   ◇◇◇◇◇◇◇◇◇◇◇◇◇◇
            ◇   ALB        ◇
            ◇◇◇◇◇◇◇◇◇◇◇◇◇◇

Arrow:      ──────────────►
            (sync call)

Dashed:     - - - - - - - -►
            (async/queue)

Component Groups

Organize your diagram into logical layers. Amazon interviewers love this structure:

1. Client Layer (top or left): Mobile app, Web browser, IoT device
2. Edge/CDN Layer: CloudFront, Route 53, WAF
3. API Layer: API Gateway, Load Balancer, Rate Limiter
4. Service Layer: Business logic microservices
5. Data Layer: Databases, caches, object storage
6. Messaging Layer: SQS, SNS, Kafka (between services)

Draw horizontal lines or use spacing to visually separate these layers.

Common Symbols Mistake: Inconsistency

The biggest mistake candidates make is using different symbols for the same concept. Pick ONE symbol for databases and use it everywhere. Amazon interviewers will notice inconsistency and it signals lack of attention to detail.

Left-to-Right vs Top-to-Bottom

There are two dominant layout patterns. Choose ONE and stick with it:

Left-to-Right (Horizontal Flow):

Client → LB → Services → Database

• Best for: Simple request-response flows
• Advantage: Mirrors how users think about requests (client sends, server receives)
• Use when: You have 3-4 layers and want to show data flowing through the system

Top-to-Bottom (Vertical Flow):

Client
  ↓
Load Balancer
  ↓
Services
  ↓
Database

• Best for: Complex systems with many services at each layer
• Advantage: More horizontal space for multiple services side by side
• Use when: You have many services in the service layer

Amazon's Preference: Most Amazon interviewers prefer top-to-bottom because it gives you room to show multiple services in parallel at each layer.

The 5-Layer Layout Template

Always start with this skeleton before filling in details:

┌─────────────────────────────────────────────────────────┐
│                     CLIENT LAYER                        │
│   ┌──────────┐   ┌──────────┐   ┌──────────┐          │
│   │  Mobile  │   │   Web    │   │   CLI    │          │
│   └────┬─────┘   └────┬─────┘   └────┬─────┘          │
└────────┼──────────────┼──────────────┼─────────────────┘
         │              │              │
┌────────▼──────────────▼──────────────▼─────────────────┐
│                     EDGE LAYER                          │
│   ┌──────────────┐   ┌──────────────┐                  │
│   │   Route 53   │   │ CloudFront   │                  │
│   └──────┬───────┘   └──────┬───────┘                  │
└──────────┼──────────────────┼──────────────────────────┘
           │                  │
┌──────────▼──────────────────▼──────────────────────────┐
│                      API LAYER                          │
│   ┌──────────────┐   ┌──────────────┐                  │
│   │  API Gateway │   │     ALB      │                  │
│   └──────┬───────┘   └──────┬───────┘                  │
└──────────┼──────────────────┼──────────────────────────┘
           │                  │
┌──────────▼──────────────────▼──────────────────────────┐
│                    SERVICE LAYER                        │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐            │
│   │  User    │  │  Order   │  │ Payment  │            │
│   │ Service  │  │ Service  │  │ Service  │            │
│   └────┬─────┘  └────┬─────┘  └────┬─────┘            │
└────────┼──────────────┼──────────────┼─────────────────┘
         │              │              │
┌────────▼──────────────▼──────────────▼─────────────────┐
│                     DATA LAYER                          │
│   ╭──────╮   ╭──────╮   ╭──────╮   (──────)          │
│   │ User │   │Order │   │Payment│   Redis  │          │
│   │  DB  │   │  DB  │   │  DB  │   Cache  │          │
│   ╰──────╯   ╰──────╯   ╰──────╯   (──────)          │
└─────────────────────────────────────────────────────────┘

Spacing and Alignment Rules

• Equal spacing between components at the same layer
• Align services horizontally at the same layer
• Group related components close together
• Leave gaps between layers to show boundaries clearly
• Center your diagram on the whiteboard — don't start at the top-left corner

Handling Multiple Services

When you have many services, use this approach:

1. Draw the main flow first (client → API → primary service → database)
2. Add secondary services on the sides
3. Use arrows to connect them to the main flow
4. Show communication patterns (sync vs async)

         ┌──────────┐
         │ Notif.   │
         │ Service  │
         └────┬─────┘
              │ (async via SQS)
┌──────┐  ┌──▼───┐  ┌──────┐  ╭──────╮
│Client├─►│ API  ├─►│Order ├─►│ Order│
└──────┘  │ GW   │  │ Svc  │  │  DB  │
          └──────┘  └──┬───╯  ╰──────╯
                       │
                  ┌────▼────╮
                  │ Payment │
                  │ Service │
                  ╰────┬────╯
                       │
                  ╭────▼────╮
                  │ Payment │
                  │   DB    │
                  ╰─────────╯

Whiteboard Real Estate

On a physical whiteboard:

• Use the top 1/3 for client/edge layers
• Use the middle 1/3 for API and service layers
• Use the bottom 1/3 for data layer
• Reserve the right side for annotations and scaling notes
• Start with pencil for the structure, then trace over with marker for final

Common Layout Mistakes

1. Cramming everything in one corner — Use the entire whiteboard
2. Overlapping components — If it looks messy, redraw it
3. Curved arrows — Use straight lines; curved lines look unprofessional
4. Missing directional arrows — Every connection needs an arrow showing data flow direction

Essential Labels for Every Component

Every component in your diagram MUST have:

1. Service/Component Name — What it is (e.g., Order Service)
2. Technology — What you use (e.g., PostgreSQL, Redis)
3. Protocol — How components communicate (e.g., HTTP/REST, gRPC)
4. Data Flow Direction — Which way data moves

Example of properly labeled component:

┌────────────────────┐
│   Order Service    │
│   (Java, Spring)   │
└─────────┬──────────┘
          │ gRPC
          ▼
╭────────────────────╮
│   Order Database   │
│   (DynamoDB)       │
╰────────────────────╯

Label Placement Rules

• Service name: Inside the rectangle, centered
• Technology: Inside or directly below the component
• Protocol: On the arrow between components
• Data type: On the arrow or next to it (e.g., JSON, Protobuf)
• Port numbers: Only if relevant to the discussion (e.g., :443)

Protocol Labels

Always label your arrows with the communication protocol:

Protocol	When to Use	Label
HTTP/REST	Standard API calls	HTTP REST
gRPC	Internal service-to-service	gRPC
WebSocket	Real-time bidirectional	WS
AMQP	Message queues (SQS)	AMQP
MQTT	IoT messaging	MQTT
SQL	Database queries	SQL

Data Store Labels

Always specify the data store type AND its purpose:

╭──────────────────╮
│   User DB        │
│   (PostgreSQL)   │  ← Primary user data
│   Primary + 2    │
│   Read Replicas  │
╰──────────────────╯

╭──────────────────╮
│   Session Cache  │
│   (Redis)        │  ← Active sessions, TTL=30min
│   Cluster Mode   │
╰──────────────────╯

╭──────────────────╮
│   Product Index  │
│   (Elasticsearch)│  ← Full-text search
╰──────────────────╯

Annotation Best Practices

Use annotations for information that doesn't fit in the diagram:

1. Scaling notes: Scales horizontally, Sharded by userId
2. Consistency notes: Eventual consistency, Strongly consistent
3. Capacity notes: 10K QPS, 99.99% SLA
4. Security notes: TLS 1.3, OAuth 2.0

Place annotations on the right side of the diagram or in callout boxes:

┌──────────┐      ┌──────────┐
│   API    ├─────►│  Order   │
│  Gateway │      │ Service  │├────┐
└──────────┘      └──────────┘     │
                                   │
                              ┌────▼────┐
                              │  Order  │
                              │   DB    │
                              ╰─────────╯

                              ┌──────────────────┐
                              │  ANNOTATIONS:    │
                              │  - Sharded by    │
                              │    orderId       │
                              │  - 5K QPS writes │
                              │  - 20K QPS reads │
                              │  - Eventual      │
                              │    consistency   │
                              └──────────────────┘

Amazon-Specific: What They Look For

Amazon interviewers specifically check for:

1. Service ownership: Each service has a clear boundary and responsibility
2. Data flow clarity: You can trace a request from client to database
3. Technology justification: You label technologies AND explain why
4. Scalability indicators: Labels showing how components scale
5. Failure handling: Annotations showing retry logic, circuit breakers

Common Labeling Mistakes

1. Unlabeled arrows — Interviewer doesn't know the protocol
2. Missing technology — Database without specifying SQL vs NoSQL
3. Too many labels — Label the important things, not everything
4. No data flow direction — Arrows without direction are meaningless
5. Inconsistent naming — Call it User Service everywhere, not UserService, user-service, UserSvc

Step-by-Step: Drawing a Chat Application Diagram

Let's practice with a complete example — a WhatsApp-like chat system:

Step 1: Identify the layers

• Client: Mobile app (sender and receiver)
• Edge: WebSocket server (for real-time)
• API: Message service, User service
• Data: Message DB, User DB, Cache
• Messaging: Queue for async delivery

Step 2: Draw the layout (top-to-bottom)

┌──────────────────────────────────────────────────────┐
│                   CLIENT LAYER                        │
│    ┌──────────┐              ┌──────────┐            │
│    │ Sender   │              │ Receiver │            │
│    │  Phone   │              │  Phone   │            │
│    └────┬─────┘              └────▲─────┘            │
└─────────┼─────────────────────────┼──────────────────┘
          │ WebSocket               │ WebSocket
┌─────────▼─────────────────────────▼──────────────────┐
│                  WEBSOCKET LAYER                      │
│    ┌──────────────────────────────────────┐          │
│    │     WebSocket Gateway (WS Server)    │          │
│    │     (Node.js, Socket.io)             │          │
│    └────────────────┬─────────────────────┘          │
└─────────────────────┼────────────────────────────────┘
                      │ HTTP REST
┌─────────────────────▼────────────────────────────────┐
│                   API LAYER                           │
│    ┌──────────┐  ┌──────────┐  ┌──────────┐         │
│    │ Message  │  │  User    │  │  Auth    │         │
│    │ Service  │  │ Service  │  │ Service  │         │
│    └────┬─────┘  └────┬─────┘  └────┬─────┘         │├──────┤
└─────────┼──────────────┼──────────────┼───────────────┘
          │              │              │
┌─────────▼──────────────▼──────────────▼───────────────┐
│                    DATA LAYER                          │
│    ╭────────╮  ╭────────╮  ╭────────╮  (────────)    │
│    │Message │  │ User   │  │  Auth  │  Redis Cache   │
│    │  DB    │  │  DB    │  │  DB    │  (Sessions)    │
│    │(Dynamo)│  │(Postgr)│  │(Postgr)│                │
│    ╰────────╯  ╰────────╯  ╰────────╯  (────────)    │
└──────────────────────────────────────────────────────┘
          │
┌─────────▼───────────────────────────────────────────┐
│                  MESSAGING LAYER                     │
│    ┌─────────────────────────────────────┐          │
│    │     SQS Queue (Dead Letter)         │          │
│    │     (Failed message retries)        │          │
│    └─────────────────────────────────────┘          │
└─────────────────────────────────────────────────────┘

Step 3: Label data flows

• Sender → WebSocket Gateway: WebSocket (real-time)
• WebSocket Gateway → Message Service: HTTP REST
• Message Service → Message DB: DynamoDB write
• Message Service → SQS: Async retry
• Receiver ← WebSocket Gateway: WebSocket push

Step 4: Add annotations

• Message DB: Sharded by chatId, 99.99% availability
• Redis: User online status, last seen, active chats
• SQS: Dead letter queue for failed deliveries
• WebSocket Gateway: Sticky sessions, 100K concurrent connections

This complete diagram tells the interviewer: you understand the problem, you know the components, you can design the data flow, and you can justify your technology choices.