What this demo shows
Decoupling heavy tasks from request-response flows so APIs stay responsive while workers process jobs in the background.
Client / Dashboard
|
| HTTP + WebSocket
v
API (Express + BullMQ Producer)
|
v
Redis Queue (email / image / ai)
|
v
Workers (email, image, ai)
|
v
Prometheus --> GrafanaIf I explain this like I am talking to you directly: this system is built so the app does not freeze when heavy work comes in. Instead of doing everything in one API request, I push jobs to queues and let background workers process them safely.
How it works: the API receives a task, validates it, and puts it in Redis via BullMQ. Dedicated workers pick jobs by queue type (email, image, AI), execute them with retries and backoff, and report status. The dashboard shows current queue health and live events.
How it benefits: fast user response times, better reliability when failures happen, safer retry behavior, and clear visibility through metrics. This is the same mindset used in real product teams when they handle async workloads.
What makes it different and unique: this is not just a basic queue demo. It combines multi-queue processing, real-time event streaming, observability with Prometheus/Grafana, and a polished monitoring UI in one system.
Why I made this: I wanted to showcase real backend engineering ownership end-to-end, not only API coding. This project demonstrates how I design systems that are scalable, observable, and ready for production-style traffic patterns.