Real-time application engineering / CASE STUDY
A real-time collaborative application
Keeping a shared session coherent across phones, reconnects, timed phases, and external-service failures.
An anonymous account of an individual product or tool I’ve worked on. Product identity and identifying operational details are withheld; the stack and engineering decisions describe implemented work.
- My role
- Product and interaction design, Python backend and browser implementation, with state-machine and integration coverage.
The problem
In a shared activity, participants can act at the wrong time, reconnect from another tab, or disappear mid-round. The application needs to agree on the current phase and recover without exposing choices before they should be visible.
Stack & system flow
- Python
- FastAPI
- WebSockets
- JavaScript
- pytest
A Python service owns the shared session state. HTTP handles explicit actions; WebSockets deliver updates. A light browser client keeps joining and participating straightforward on a phone.
Simplified flow
- Join session
- Submit action
- Validate phase
- Update shared state
- Broadcast view
Engineering decisions
Make the server own the phase
The server validates actions against the current session state. Clients receive an appropriate view of that state rather than each independently deciding when a round has moved on.
Exercise reconnects as normal behavior
Presence updates, a replacement connection, timed transitions, and late participants are part of the workflow. Integration tests exercise these boundaries along with a complete round through the application interface.
Keep sessions temporary
Rooms live in memory and expire. That avoids account and history management for a short-lived experience, but deliberately gives up durable session recovery and a distributed state model.
What was implemented
The implementation includes live session updates, explicit phase transitions, host and participant actions, and expiry. External lookup failures surface as recoverable failures rather than silently accepted actions.
Representative regression coverage
- WebSocket tests cover the initial snapshot, presence, reconnect replacement, and malformed or oversized messages.
- API tests exercise a complete round and reject actions in the wrong phase.
- Fake clocks and external-service doubles make timeout and dependency-failure cases repeatable.
These examples describe repository tests reviewed for this case study, rather than a new production audit.
Tradeoffs & limits
This is an ephemeral, single-process application. The reviewed tests do not establish distributed consistency, durable recovery after a restart, or a sustained throughput benchmark.