Payment Observability
How do you let people ask an LLM about live operational data without letting it see more than it should?
A real-time dashboard that replays synthetic payment events through an event bus, a risk engine and a guarded conversational analyst.
Events in, insight out
Transactions flow through a producer, an in-memory event bus and an incremental analytics engine into a Redis KPI cache, then out over WebSockets as an initial snapshot plus live updates. The browser never reads a database. Source adapters all publish the same event contract, so nothing downstream cares where events come from.
- Synthetic generator
SQLite demo store
- Replay producer
pause · resume · reset · fast-forward
- Event bus
- Analytics + risk engine
refusals, timeouts, latency, anomalies
- KPI cache
- Redis
- in-memory fallback
- FastAPI
- REST
- WebSocket
- guarded analyst
A conversational analyst with guardrails
The assistant answers questions about KPIs, anomalies, architecture and replay state through whitelisted tools with bounded queries, rate limits and response sanitisation. It falls back to rules when no model is configured, can use a local Ollama model, and optionally a hosted one.
One more section for engineers: architecture, hyper-parameters and design decisions.
Under the hood
Under the hood- Backend
- FastAPI, Uvicorn, Pydantic, aiosqlite, async services with clear boundaries
- Realtime
- WebSocket snapshot + deltas, optional token for non-local deployments
- Cache
- Redis KPI snapshots with automatic in-memory fallback
- Frontend
- React 19, TypeScript, Vite, Tailwind, ECharts
- Tests
- Aggregation, replay state, API/WebSocket contracts, chatbot safeguards, cache behaviour, reconciliation, interpolation
What it doesn't do (yet)
- The public version runs on generated demo data. It demonstrates patterns, not production scale.
- The conversational analyst answers from whitelisted tools and local knowledge; it is not a general SQL interface by design.