TL;DR
I built OpsFlow, an incident management SaaS for small ops teams: log incidents, assign severity, track SLA deadlines, and notify the right people in real time. Under the hood it's a microservice setup (API, frontend, and a separate notification service) that talks over Kafka. For a tool with a modest number of daily incidents, that's arguably more infrastructure than the traffic justifies, and that trade-off is worth being honest about.
What OpsFlow actually does
OpsFlow lets a team log an incident, assign a severity level, and track it against an SLA deadline. Every organization is multi-tenant isolated, every user has a role (RBAC) that controls what they can see and act on, and every state change (acknowledged, escalated, resolved) needs to reach the right people immediately, not on the next page refresh.
Why a separate notification service
The part that pushed OpsFlow toward a microservice split wasn't the incident CRUD (that's a normal REST API), it was notifications. Every incident state change can fan out to multiple channels and multiple people, and that work is bursty and shouldn't block the request that created the incident. So the API publishes an event to Kafka when something changes, and a dedicated notification service consumes those events and handles delivery. The incident API stays fast and simple; the notification service can retry, batch, or slow down without the person filing the incident ever noticing.
Was Kafka overkill?
Honestly, for OpsFlow's actual traffic, a Redis-backed job queue would have handled the load with a fraction of the operational surface. Kafka's real value here isn't throughput, it's the durable log: notification delivery failures don't lose the event, consumers can replay from an offset, and adding a second consumer later (an audit log service, for example) doesn't mean touching the producer at all. That's a real architectural benefit for a product built around "did the right person get told," even if the queue depth on any given day is small.
RBAC and SLA tracking, on the same event stream
Roles determine both visibility and action: who can see an incident, who can change its severity, who can close it. SLA tracking runs off the same event stream. An incident's assigned severity determines its deadline, and the notification service watches for approaching and breached deadlines the same way it watches for state changes, as events, not as a separate polling job.
The stack
Express.js, React, React Native, TypeScript, PostgreSQL, Kafka, Redis, MUI.
Try it
OpsFlow is live at opsflowweb.vercel.app, source on GitHub: akincskn/opsflow-api.
I'm Akin Coskun, a full-stack developer from Turkey building production SaaS tools with zero-cost infrastructure. More projects on my portfolio: akin-coskun.web.app.
Top comments (0)