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
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.
- High-volume event intake
- Tenant-scoped API key / JWT auth
- Redis + BullMQ
- Retry with backoff
- Dead-letter queue
- Idempotent handlers
- Tenant isolation at the DB layer
- Usage metering
- Billing limits
- Modular monolith
- Event-driven modules
- One deployable
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.