LLD vs HLD
High-level design allocates system responsibilities across services and infrastructure. Low-level design specifies the contracts and behavior inside a chosen boundary.
What you’ll understand
- High-level design allocates system responsibilities across services and infrastructure. Low-level design specifies the contracts and behavior inside a chosen boundary.
- Practice explaining a design decision with an example and a boundary case.
Two scales of the same problem
For a notification product, HLD asks how traffic reaches delivery workers, where subscriptions are stored, and how failures are retried. LLD asks how a channel is selected, what send returns, how an adapter normalizes vendor responses, and whether an opted-out subscriber is skipped. Both views should agree about the business behavior.
- HLD example: a durable queue separates producers from workers.
- LLD example: DeliveryResult distinguishes delivered, failed, and unsupported.
- Connect the views through explicit service contracts.
Keep the interview at the requested scale
An LLD discussion can mention persistence or concurrency when they affect a method’s contract, but it need not design a global cluster. Conversely, a method-level class diagram does not prove that a distributed system can meet an availability target. Ask which scale the interviewer wants before spending time on a diagram.
- Discuss atomicity when two callers can reserve the last item.
- Defer shard counts when designing an in-process allocation policy.
- State assumptions instead of silently changing scope.
Move between the views
Choose a library loan operation. First name the service boundary and storage dependency. Then describe the object identities, validation order, and result of borrow(copy, member). This exercise reveals which guarantees belong at each level.
- Which component rejects an already-loaned copy?
- Which data must survive a restart?
- Does a retry duplicate the loan or return the earlier result?