Tanuj Pant

A user message is persisted by the backend and pushed onto a Redis queue. An agent worker picks up the job, loads the conversation from Postgres, and executes the agent loop inside the conversation's Kubernetes workspace.

The workspace contains separate agent and app-runner containers sharing a PVC. The agent edits the project while the app-runner owns the development server and exposes the generated application through Kubernetes Service and Ingress. Progress flows through Redis Pub/Sub → backend → WebSocket → browser.

The system persists the conversation before agent execution begins, so a failed agent run doesn't lose the user's request.

Conversation state is stored in Postgres rather than process memory, while chat history is also backed up to S3-compatible storage. If a workspace pod fails, it can be recreated and the conversation restored from persistent state rather than relying on the previous pod surviving.

Long-running agent work is asynchronous, allowing the API and WebSocket layers to remain independent of the execution time of a coding task.

The app-runner is separated from the agent so generated applications can restart independently when files change. Sub-agents can also work on isolated Git worktrees, allowing focused tasks to execute without competing over the primary workspace.

A dedicated Kubernetes workspace per conversation provides strong isolation but introduces significant resource overhead.

The shared PVC simplifies communication between the agent and app-runner, but also means workspace lifecycle and storage have to be managed separately from pod lifecycle.

The architecture also deliberately keeps some production concerns open: authorization, secrets management, autoscaling, resource limits, retry/dead-letter handling, and multi-replica WebSocket scaling remain production-readiness work.

The API backend validates authenticated requests and pushes transactions into Redis Streams. The matching engine consumes those events and maintains the exchange state entirely in memory, handling order matching, margin verification, position tracking, and PnL calculations.

Execution results are consumed independently by the DB writer and WebSocket server, keeping persistence and client updates off the matching path. The services can run as Bun processes or as containerized workloads on Kubernetes.

The engine intentionally processes all tickers sequentially. This avoids distributed coordination around shared user balances and, more importantly, guarantees that replaying the same event sequence produces the same decisions.

For persistence, the system generates a correlation ID at the origin of a user action. The DB writer uses that ID as a unique key inside a database transaction, preventing duplicate mutations even when the same logical operation is delivered multiple times.

The matching engine periodically serializes its state and stores immutable snapshots in S3. After a restart, it loads the latest snapshot and replays the Redis Stream from the corresponding offset to reconstruct the state.

This gives the system two recovery mechanisms working together: snapshots reduce replay time, while the event stream provides the missing history after the snapshot.

Keeping the matching state in memory avoids database round trips on the critical execution path, with the system targeting sub-millisecond transaction execution.

The trade-off is deliberate: a single sequential engine limits horizontal scaling of the matching path. The design prioritizes deterministic execution and financial consistency over independently scaling multiple matching-engine instances.