How I Designed a Real-Time Dashboard Using Kafka, Socket.IO, and a BFF

A practical breakdown of the architecture decisions, trade-offs, and frontend/backend boundaries behind Flux — an event-driven real-time dashboard platform I built. When I started building Flux, I didn’t want to build just another dashboard. I wanted to build something that actually felt like a real-time system. Not a frontend that keeps polling every few seconds. Not a UI that directly calls five different APIs. Not a project where everything works only when the happy path works. I wanted something closer to how production systems are usually designed: multiple data domains asynchronous communication real-time delivery graceful degradation and a frontend that stays simple even when the backend gets more complex So this post is a breakdown of how I designed the architecture for Flux — and more importantly, why I made the decisions I made. What Flux actually is Flux is a real-time dashboard that streams and displays: Weather News Stocks Crypto At first glance, it looks like a frontend-h