UML (Unified Modeling Language) provides a standardized visual notation for software architecture, with 14 diagram types organized into structural (what the system is) and behavioral (how the system works) categories. For system design interviews and architecture documentation, the most valuable are: Sequence Diagrams (temporal ordering of interactions between components), Component Diagrams (system decomposition and interfaces), and Deployment Diagrams (physical mapping of software to infrastructure). UML is prescriptive but teams often use a lighter informal notation (boxes and arrows) — the goal is communication clarity, not notation purity.

Key Points

  • Sequence diagrams show lifelines (vertical dashed lines per component), synchronous calls (solid arrowhead), asynchronous messages (open arrowhead), and return values (dashed line) — ideal for documenting API flows.
  • Component diagrams use the "lollipop" notation for provided interfaces and "socket" for required interfaces — clearly shows what each component offers and depends on.
  • Deployment diagrams show Nodes (physical or virtual machines), Artifacts (deployed software), and Communication Paths (networks) — maps the software architecture to infrastructure topology.
  • Activity diagrams (flowcharts with swim lanes) are more readable than sequence diagrams for business process flows with branching, parallelism, and loops.
  • Class diagrams show inheritance (hollow triangle), composition (filled diamond — whole destroys parts), aggregation (hollow diamond — whole does not destroy parts), and association.
  • State machine diagrams model object lifecycle — invaluable for documenting order states (Created → Confirmed → Shipped → Delivered → Returned) and connection state machines.
  • Use Case diagrams are often misused — they communicate actor-system interactions at a business level, not implementation details; reserve them for stakeholder-facing documentation.
  • PlantUML, Mermaid.js, and draw.io enable "diagram as code" embedded in repositories — diagrams stay synchronized with the code they describe, avoiding documentation rot.

Real-World Example

Amazon's internal "Working Backwards" product process uses UML-inspired sequence diagrams to validate API designs before a single line of code is written — the practice of documenting API interactions forces the team to discover ambiguities in the design while change is still cheap. This practice directly reduces the cost of API redesigns discovered post-implementation.