core practice · system design prompt
Design exercise: Real-time Application Engineering
WebSockets, server-sent events, presence, synchronization, ordering, reconnects, optimistic UI, and conflict handling. Implement designOutline() returning non-empty values for: connectionLifecycle, ordering, reconciliation. Each value must name a concrete mechanism or decision.
The mechanism
Realtime messaging is two problems wearing one name. On the server it is long-lived connections plus fan-out: WebSockets are stateful, which constrains your load balancer, and choosing per-channel versus per-user fan-out is the central design decision. On the client it is maintaining a local projection of remote state that survives disconnects and reordering — so the protocol needs message identity, a sequence number, a reconnect-and-catch-up path, and a reconciliation rule for optimistic updates the server later rejects.
Expected evidence
A design outline with connectionLifecycle, ordering, reconciliation plus an explicit failure mode or trade-off.
Try this drill in the practice workspace →
Hints when you need them
- Name the failure mode before selecting the mechanism.
Watch for these mistakes
- Sticky sessions as the only fan-out plan, so one hot channel pins to one node
- No sequence number, leaving the client unable to tell a reconnect gap from an ordering swap
- Optimistic UI with no reconciliation path when the server rejects the write