Salient

04 Case study

SignalOps

SignalOps is a modular-monolith backend platform for high-volume event ingestion. Strict tenant isolation, idempotent processing, and billing limits enforced where they cannot be bypassed: at the database layer.

Client
Open engineering work
Sector
Backend platform / multi-tenant SaaS
Year
2025
Role
Architect and builder
Engagement
Platform design
1Codebase, modular by boundary, not by repo
2Auth modes: API key and JWT, tenant-scoped
0Cross-tenant reads possible by design

The problem

Multi-tenant platforms usually enforce isolation in application code, which means isolation is one forgotten where-clause away from a breach. Under high-volume ingestion, retries and duplicate deliveries turn every non-idempotent handler into silent data corruption.

Microservices are the reflex answer and the wrong first move for a small team. The operational cost arrives immediately; the benefits arrive at a scale most products never reach.

The approach

SignalOps is a modular monolith: hard module boundaries, one deployable. Event ingestion flows through an async pipeline on Redis and BullMQ with retry, backoff, and a dead-letter queue, so failure is a state to inspect, not an exception to lose.

Isolation and limits live at the database layer. Tenant-scoped auth covers both API keys and JWTs, usage metering is recorded per tenant, and billing limits are enforced where application bugs cannot route around them.

Every handler is idempotent. Duplicate delivery is treated as the normal case, because at volume, it is.

Architecture

One deployable with hard internal seams. The queue absorbs volume; the database enforces the rules.

The hard parts

Isolation that survives bad code

The design assumes application bugs will happen. Tenant boundaries are enforced at the database layer, so a missing filter in a handler fails closed instead of leaking another tenant's data.

Making failure boring

Dead-letter queues, backoff, and idempotency keys turn worst-case scenarios into routine operations: inspect the DLQ, fix, replay. No 2am archaeology.

Outcome

A reference architecture the studio now applies to client backends: modular monolith first, queues for volume, invariants in the database.

The public codebase doubles as proof of how the studio thinks about correctness under load.

Source available on GitHub.

NestJSTypeScriptPostgreSQLRedisBullMQ
Next case study 05Hanuneeb