Real-Time AI Chat Backend

Build a small real-time chat backend. Authenticated users open WebSocket connections, join conversations, and exchange messages with an AI assistant. Messages are broadcast live to all connected clients of a conversation and persisted to Postgres. Redis pub/sub fans messages out across multiple server instances. This is a backend role: we are not testing AI, but we want to see that you can design a clean real-time API, handle connection lifecycle correctly, and ship something typed, tested, and horizontally scalable. Scope honestly. A smaller service that is solid and well-reasoned beats a big half-working one. Anything marked "nice to have" is optional, so skip it and say why. Your role  This is a backend build. The "AI" is not the point: write a tiny mock that returns a canned or echoed reply (optionally with a fake streamed/token-by-token response over the socket). Your job is the server: auth, the WebSocket layer, the Redis fan-out, and durable persistence. What You Must Build 1 Auth + Sessions Email/password sign-up & login. Issue JWT access tokens (short-lived) + refresh tokens. WebSocket connections must authenticate (pass the token in the connection handshake via query param, subprotocol, or first message; justify your choice). Reject unauthenticated or expired-token connections cleanly with a proper close code. Hash passwords (argon2/bcrypt), never store plaintext. 2 Conversations & Persistence REST endpoints to create, list, rename, and delete conversations. Messages persist per conversation in Postgres with sender, role (user/assistant), content, and timestamp. A client can fetch message history (paginated) on join. Schema via migrations (Alembic), not manual SQL. NICE TO HAVE soft-delete + restore; cursor-based pagination over offset. 3 Real-Time Messaging (the core) WebSocket endpoint per conversation. When a user sends a message: persist it, broadcast it to all connected clients of that conversation, then generate the mock assistant reply and broadcast that too. Use Redis pub/sub so a message sent to one server instance reaches clients connected to a different instance. This must work with 2+ app replicas. Handle disconnects, reconnects, and dead connections without leaking. Define a clear JSON message protocol (message types, ids, errors). NICE TO HAVE typing indicators / presence; streamed assistant reply (token chunks over the socket); per-user rate limiting via Redis. 4 Robustness & API Design Clean separation (routing / service / repository or equivalent). Pydantic models at the boundary; validation errors return structured responses. A failed AI call or DB hiccup must not kill the socket or crash the worker. Graceful shutdown drains/closes sockets. Sensible structured logging. Senior Backend Engineer · Technical Test Assignment 1 / 3 Bonus (optional: pick at most one, only if you have time) Message delivery guarantees: dedupe via client-supplied message id; at-least-once redelivery on reconnect. Observability: /health + /metrics (Prometheus) with active-connection and message-throughput counters. OAuth login: Google/GitHub via standard OAuth2 alongside email/password. Horizontal-scale proof: load test (locust/k6) showing fan-out across 2 replicas, with numbers. Baseline Expectations (don't overthink these) Async done right: no blocking calls in the event loop (async DB driver, e.g. asyncpg; no sync requests). Connection/session lifecycle managed properly. Security: secrets via env, none committed. Passwords hashed. Tokens validated on every connection and privileged call. Reasonable CORS. Code quality: typed throughout; mypy/pyright and ruff/flake8 pass. Errors handled at the network/DB boundary so the app doesn't crash on a failed request. Tests (light): a couple around send/persist/broadcast or token validation. A test proving cross-instance fan-out (or the broadcast logic) is a strong signal. Full coverage not expected. Service: docker compose up brings up the API + Postgres + Redis on a clean checkout. Migrations run automatically or via one documented command. Mock AI: bundled into the app or a one-command local script. README.md: how to set up, run, and test. List anything that doesn't work yet. NOTES.md (short): how it's structured, your WebSocket auth + message protocol decisions, what you'd do next, and an honest self-critique of what you cut. A way to see it work: either a short screen recording or a documented script/Postman/websocat sequence that goes sign up → open a socket → send a message → see the broadcast + assistant reply → reconnect and see history. Bonus credit for showing two replicas exchanging a message via Redis.