Introduction

If you are adding a realtime healthcare intake avatar, the architecture choice matters more than the avatar itself. You are not just rendering a talking face; you are moving audio, turn-taking events, session state, and often personally sensitive user input through a latency-sensitive system. The usual question is whether to put the application behind FastAPI or to build a dedicated WebSocket worker. The short answer is: use FastAPI for control-plane and request/response work, and use a WebSocket worker for the media/session plane when you need continuous bidirectional realtime traffic.

This post explains the difference in practical terms, what each component is good at, where they fail, and how to decide for a healthcare intake flow. By the end, you should be able to sketch a sane architecture for a voice-driven intake avatar without overloading your web app, blocking event loops, or mixing long-lived media sessions with normal HTTP request handling.

What FastAPI is good at, and what it is not

FastAPI is excellent for APIs that create, configure, and authorize realtime sessions. It is built on standard HTTP semantics: request arrives, you validate input, you return JSON, and the connection ends. That makes it a strong fit for:

• creating an intake session record

• issuing ephemeral tokens or signed session parameters

• looking up patient-specific configuration

• receiving webhook callbacks from upstream services

• persisting transcript snippets, status updates, or audit events

In a healthcare intake system, those are the parts you want to keep deterministic and easy to inspect. FastAPI gives you typing, validation, dependency injection, and clean integration with your persistence layer. It also scales well for stateless request/response traffic.

What FastAPI is not ideal for is owning a large number of long-lived bidirectional media connections. You can technically use WebSockets inside FastAPI, but once you start moving audio frames, avatar sync messages, interruption events, and turn-state transitions through those sockets, you are operating a streaming system, not an HTTP API. That changes everything about backpressure, lifecycle management, and failure handling.

The practical rule: if the request is short and the response can wait until the end of the HTTP transaction, use FastAPI. If the interaction is continuous and latency-sensitive, isolate it in a worker designed for long-lived realtime sessions.

Why a WebSocket worker exists at all

A WebSocket worker is a process whose primary job is to maintain realtime sessions and react to streaming events as they arrive. It is not just “a FastAPI route with a socket.” It typically handles:

• audio ingress from the client or from an upstream voice stack

• incremental speech-to-text or agent turn updates

• avatar timing signals for lip sync and expression changes

• interruptions, barge-in, and turn switching

• session heartbeats and disconnect recovery

Healthcare intake flows are full of state transitions. A patient may speak over the agent, pause mid-answer, restart, or get routed to a human. The avatar should track those changes immediately. That means the session worker must maintain in-memory state and respond in milliseconds, not wait for a general-purpose request handler to schedule work alongside unrelated API traffic.

Using a separate worker also keeps your operational boundaries clean. You can autoscale workers based on concurrent sessions, terminate stuck sessions independently, and keep your HTTP application responsive even under load. In practice, this separation is usually the difference between a system that is merely functional and one that survives real traffic.

The main trade-off: control plane vs media plane

The cleanest way to think about this is to split your system into two planes:

• Control plane: FastAPI handles session setup, identity, policy checks, and persistence.

• Media plane: a WebSocket worker handles the realtime session itself.

For a patient intake avatar, the control plane might decide whether the user is allowed to start a session, which language the intake should use, and which questionnaire should run. The media plane then manages the live conversational session, including the avatar’s synchronized video face and the turn-by-turn interaction.

This separation matters because the failure modes are different. If FastAPI is slow, a new session may take a few extra hundred milliseconds to initialize. If the worker is slow, the user hears lag, sees desynchronized lip movement, or experiences broken turn-taking. Those are not equivalent failures. Only the second one is directly visible to the patient.

There is also a security angle. Your HTTP app usually sits behind normal auth, rate limits, and audit logging. Your realtime worker should not need full application privileges; it should receive only the minimum session metadata required to operate. That is a better fit for least privilege and easier incident response.

A practical FastAPI pattern for session creation

The HTTP endpoint should create a session and return whatever the client or worker needs to connect. Keep it thin. Do not try to negotiate the entire realtime protocol in your endpoint.

from fastapi import FastAPI, Header

}

from fastapi import FastAPI, Header

}

from fastapi import FastAPI, Header

}

This stays boring on purpose. The endpoint should authorize, persist, and hand off. The worker then consumes that session ID and starts the realtime conversation.

What the WebSocket worker should actually do

Your worker should own the interaction loop. That means it should listen for events, update state, and emit the next action without round-tripping to the HTTP app for every turn. For a voice intake avatar, that often includes:

1. accepting session metadata at connect time

2. joining the voice stream or receiving upstream audio events

3. tracking the active speaker and current turn

4. forwarding agent output to the avatar renderer

5. closing the session cleanly when complete

A common mistake is to keep all conversation state in the FastAPI process and have the worker call back for every update. That couples your realtime path to your web app’s latency, queueing, and deployment cadence. If your intake volume grows, that coupling will become a bottleneck. Keep the worker self-sufficient during the live session and only sync durable state back to your API when needed.

Another mistake is to treat WebSockets like long-polling. If you are waiting for server responses in a strict request/response pattern, you are paying the complexity cost of sockets without getting their benefit. Use them when you truly need continuous two-way stateful communication.

Where Protoface fits in this architecture

This is exactly the kind of split Protoface is designed to support. Your FastAPI app can remain the control plane, while the realtime session logic lives in the media plane. For voice-agent stacks built on LiveKit, the LiveKit integration is the cleanest path: the plugin drops a synchronized talking face into an existing agent so you do not have to hand-roll avatar timing yourself. If you are working in Python, the SDK and REST API let you create and manage avatars and sessions from your own backend, while keeping API keys out of the browser.

For teams already running an intake workflow in FastAPI, the useful pattern is simple: create the session in your API, hand the client or worker the session metadata, and let the realtime layer own the connection. The exact request and response fields depend on the surface you use, so check the documentation for the current API and SDK shapes.

from protoface import ProtofaceClient

print(session)

from protoface import ProtofaceClient

print(session)

from protoface import ProtofaceClient

print(session)

If your stack is LiveKit-based, the plugin route is usually lower-friction than building your own avatar sync layer. You keep your existing agent logic and add the visual layer as an integration concern instead of a separate product.

Healthcare-specific gotchas

Healthcare intake adds constraints that change the engineering trade-offs:

• Latency is user experience: even a small delay before the avatar responds makes the flow feel unreliable.

• Session state may be sensitive: keep PHI out of logs, metrics labels, and client-visible payloads.

• Auditability matters: the control plane should record who started a session, when, and under what policy.

• Failures should degrade cleanly: if the avatar session fails, the intake should fall back to text or a human workflow.

These constraints push you toward a split architecture. FastAPI gives you traceable policy and persistence. The WebSocket worker gives you responsive turn-taking. Trying to collapse both into one layer usually makes the system harder to debug and less predictable under load.

Conclusion

For realtime healthcare intake avatars, FastAPI and WebSocket workers are not competing choices so much as complementary ones. FastAPI should handle session creation, authorization, storage, and orchestration. The WebSocket worker should handle the live conversational session, media events, and avatar synchronization. If you keep those responsibilities separate, you get simpler code, better scaling, and fewer latency surprises.

Start by building a thin FastAPI control plane, then move the live avatar session into a dedicated worker. If you want to shorten the integration path, review the docs at docs.protoface.com and the relevant integration repo for your stack. That will get you to a working realtime avatar without forcing your main API to pretend it is a media server.