Problem context and objectives
New systems architect · A cross-platform game party service
Explain the same feature at HLD and LLD without mixing the two levels of detail.
If the architecture has no clear boundaries, teams cannot own or scale it. If the component internals have no contracts, concurrent invites and joins corrupt party state.
How you win
- 1HLD shows users, services, data, and communication boundaries
- 2LLD shows interfaces, state transitions, validation, and concurrency rules
- 3Every detail answers a requirement at the correct zoom level
Rules and pressure
- 10M daily players
- Party size: 1 to 8
- Invite acceptance must be idempotent
- A party may enter matchmaking only once
New words in this mission
Open a term for a plain-language explanation.idempotent operation+
Repeating the same request has the same final effect as doing it once. This makes automatic retries safe.
Live architecture trace
The Two Design Lenses: request to outcome
Player app sends “party command” to Party API. HLD is the system map: actors, major components, data stores, communication, trust boundaries, deployment shape, and the qualities the design must achieve.
A studio needs a party service for players who create a party, invite friends, choose a game mode, and enter matchmaking. Learn when to use high-level design and when to zoom into low-level design. Follow one real user action through the complete architecture; a component is useful only when you can explain the request, state, or failure it handles.