Drawing Clear Diagrams

Make the diagram tell the story

For HLD, draw the request path left to right (client, edge, services, stores), label every arrow with what flows ("POST /rides", "location events"), and mark sync versus async calls. Keep one diagram for the overview and zoom into a component separately rather than cramming detail. For LLD, draw a lightweight class diagram: classes with a few key fields and methods, interfaces marked, and relationships shown as inheritance, composition or association with multiplicities. Walk the interviewer through one concrete use case on the diagram; it exposes gaps faster than describing boxes in the abstract.

Communicate the design

A correct design still needs clear diagrams, explicit trade-offs and practice under time pressure.

A compact class diagram in text

Parking lot, UML-like notation.

<<interface>> PricingStrategy          <<interface>> SpotAllocationStrategy
   + priceInCents(ticket, exit)            + allocate(floors, type)
        ^                                        ^
        | implements                             | implements
  HourlyPricing                             NearestFirstAllocation

ParkingLot 1 *-- * Floor 1 *-- * ParkingSpot      (*-- composition)
ParkingLot --> PricingStrategy, SpotAllocationStrategy   (uses)
Ticket --> Vehicle, ParkingSpot                       (association)
EntryGate / ExitGate --> ParkingLot

Number the steps

Numbering arrows in the order a request flows (1, 2, 3...) lets the interviewer follow your walkthrough and refer back to a specific step.

Quick check: What makes an HLD diagram easier to follow?

• Drawing every class in the system
• Using as many boxes as possible
• Omitting data stores
• Labelled arrows showing what flows and whether calls are sync or async