One request, one outcome: a WebSocket design lab
An interactive exploration of request IDs, deadlines, and duplicate handling, with the boundaries that make a small simulation useful.
Lab Protocol design · Completed
WebSocket request / response playground
An interactive Lab for exploring request IDs, deadlines, server failures, and duplicate requests. Change the conditions and watch each operation settle.
Try the playground ↓- Role
- Designer and engineer
- Timeline
- Sep 2026
- Technology
- TypeScript · Astro · Web Components
Lab / 01
WebSocket request / response
What happens when a reply is late, fails, or arrives twice? Change the conditions, send a request, and follow its outcome.
Browser-local simulation · no server connection
- Pending
- 0
- Successful
- 0
- Failed
- 0
- Timed out
- 0
| Request ID | Status | Latency / timeout | Extra copies |
|---|
No requests yet. Start with a scenario or choose your own conditions.
Event timeline · newest first
Up to 40 operations and the latest 100 events per run. Clear the run to start again.
Problem
A message channel does not define how a product should match replies, stop waiting, or handle repeated requests. Those decisions need an explicit application protocol.
Constraints
- Runs on this static site, with no backend or external connection.
- Demonstrates application behavior, not network performance or the full WebSocket lifecycle.
My role
I built a browser-local simulation that makes request lifecycles visible, with configurable conditions and an inspectable event timeline.
Key decisions
Match by request ID
Each operation has a unique ID. Duplicate deliveries retain that ID, so they remain one logical operation.
Settle once
Success, an application error, or a deadline ends the wait. Late and duplicate replies stay visible in the timeline but cannot change the outcome.
Reuse the server result
The simulated server computes one result per ID. Extra copies replay it instead of executing the operation again. This is a teaching model, not a durable idempotency store.
Results
- Four observable states, configurable latency and failures, duplicate deliveries, and repeatable presets.
- A bounded run with at most 40 operations and 100 recent events; clearing cancels outstanding timers.
Lessons
- A timeout ends the client wait; it does not prove the server did nothing.
- Client-side reply suppression and server-side idempotency solve different parts of the problem.
Try these three comparisons
- Send a request on the Happy path, then send another with lower latency before the first finishes. Completion order can differ from send order.
- Choose Late reply, send a request, and wait. The operation times out; its eventual reply is logged and ignored.
- Choose Duplicate requests and send once. Three deliveries share one request ID, one server execution, and one client outcome.
Failures here are explicit application errors, not dropped packets. The model omits connection establishment, reconnects, authentication, and durable storage. The companion article explains where these boundaries matter.