← All work

The system everything else runs on

High-Throughput Backend Platform

The centralized NestJS/BullMQ/Redis backend that absorbs high-volume webhooks and background jobs — the spine the rest of the platform depends on.

Problem

As the product grew, it needed a centralized backend that could absorb high-volume webhooks (Gmail / Outlook) and run background jobs reliably — the spine the rest of the platform depends on.

Approach

Architected a centralized, high-throughput backend on NestJS with BullMQ and Redis for queue-backed job processing. Built a full observability stack with OpenTelemetry, structured logging, and error tracking so failures surface fast and root-cause analysis stops being guesswork. Re-architected the platform to support multi-tenant organizations with a granular permission model.

Impact
  • Processes high-volume webhooks and background jobs the whole platform relies on
  • Sharply reduced root-cause analysis time across the team via observability
  • Re-architected for multi-tenant orgs with a granular permission model and stronger isolation

Why queues, not request/response

Webhooks from Gmail and Outlook arrive in bursts you don’t control — a customer connects an inbox and suddenly there’s a flood of events. Processing them inline would mean dropping events under load or timing out the provider’s webhook. So the backbone is queue-first: webhooks land, get acknowledged immediately, and the real work happens in BullMQ workers backed by Redis. That decoupling is what lets the platform stay up when traffic spikes.

Making failure legible

Early on, debugging a failed job meant guessing. I built out OpenTelemetry tracing, structured logging, and error tracking so that when something breaks, you can follow a single request across services instead of grepping logs. That one investment cut root-cause analysis time across the whole team.

Multi-tenancy

As the customer base grew, I re-architected the platform around multi-tenant organizations — a granular permission model, project and org invitations, and stronger security isolation between tenants so one customer’s data and config never bleeds into another’s.

← Back to all work