A. Cerqua
#01

Realtime Client

Role Frontend lead, three-developer team Period 2026 Sector Real-time analysis platform

Brief

A platform that watches a live conversation and produces a continuous read on it, for people rehearsing or reviewing high-stakes calls. A separate analysis engine emits a dense block of signal on every tick. Everything else, the product around it, had to turn that stream into something a person can glance at while their attention is mostly elsewhere.

Constraints

  • The analysis engine is a separate service on its own release cycle, and its output shape moves as its models change.
  • The signal arrives continuously, per tick, for the whole length of a session.
  • The interface is looked at sideways, during a call, by someone whose attention is on the call.
  • Live audio and video transport, session state, and the analysis stream all have to stay in step.

Architecture

LIVE CALLLIVEKITENGINENOT MINEMONGORAW, PER TICKENRICHMENTLAYERSTABLE SHAPEWEBSOCKETTO CLIENTLIST ENDPOINTSHTTPANALYZERSGEMINIPOSTGRESAPP STATEREPLAY: STORED SESSIONS RE-RUN OFFLINE
Fig. 1 / The stable contract, in red

How it works

  • Audio and video run over a real-time media service rather than a hand-rolled transport, so the product does not own connection negotiation, reconnection or media codecs.
  • The engine writes one document per tick to a document store. Application state, users, sessions, contacts and settings, lives in a relational database. The split follows the shape of the data instead of forcing both into one store.
  • An enrichment layer sits between the engine and everything downstream. It translates the raw engine output into a stable wire shape, and every consumer, the sockets, the list endpoints, the model prompts, reads only the enriched form.
  • That layer has exactly one documented exception, a lineage job that still reads raw documents because it needs a field the enriched shape drops. The exception is written down rather than left to be discovered.
  • Enriched blocks are pushed to the client over a websocket, separate from the media path, so the analysis stream and the call do not share a failure mode.
  • Replay scripts re-run a recorded session through the analyzers offline, so a prompt or scoring change can be evaluated against real past sessions instead of by starting a new call.

My part

  • The frontend, which is the largest single area of the codebase I wrote: the component library, the application routes, the composables, and the typed API client.
  • The analysis-session service on the backend, which is the domain core: session lifecycle, the event record, and the contact and observation model around it.
  • The replay tooling for the supervisor and companion analyzers.
  • Not mine: the analysis engine itself, which is a separate Python service I did not work on, and the majority of the backend, which was written by the lead.

Outcome

The product around the engine holds a stable contract with it, so the engine can change without breaking every consumer at once. A recorded session can be replayed through the analyzers offline, which turns prompt changes from a live experiment into something testable.

Stack

SvelteKitFrontend application, static build
LiveKitReal-time audio and video transport
FastifyAPI surface and websocket server
PostgreSQL / Drizzle ORMRelational application state
MongoDBHigh-volume per-tick engine output
Google GeminiThe analyzers reading the enriched stream