Templates/SaaS Application

SaaS Application

Web ApplicationProductionTeam-scale product

Baseline SaaS architecture with sync APIs, async job processing, webhook billing, and cache layer. Suitable for scalable web apps with background workloads.

Recommended for: SaaS teams shipping subscription products

13 nodes17 connectionsHot-path cachingBackground jobsFailure isolation

Scope Notes

Intended for SaaS teams shipping subscription products at Production complexity and Team-scale product scope. Treat the graph as a starting shape rather than a fixed stack: keep the topology and the signals below, then swap providers to match your platform.

Hot-path cachingBackground jobsFailure isolation

Review Checklist

0 of 12 reviewed

Use Case

SaaS products, subscription platforms, dashboards

Best Fit Scenarios

  • B2B SaaS with billing and user roles
  • Product teams splitting sync APIs from async workers
  • Teams that need error visibility from day one

Stack Breakdown

ReactNext.jsNestJSPostgreSQLRedisBullMQ

Architecture Layers

1Client SPA
2SSR + API gateway
3Core services
4Data, cache & queue
5Async workers
6External integrations & secrets

Components by Category

frontend

ReactNext.js

backend

API GatewayAuth ServiceNestJS

async

Worker ServiceBullMQDead Letter Queue

database

PostgreSQLRedis

external

StripeSentry

infra

Vault

Why This Topology Works

Frontend concerns stay separate from business logic behind an API gateway. Auth, billing and monitoring are distinct services, and the BullMQ queue keeps expensive work off the request path. Stripe webhooks arrive through the gateway rather than being triggered by the auth service.

Scaling Notes

NestJS and the workers scale horizontally behind the gateway. Redis caches sessions and hot reads, PostgreSQL is the system of record, and Auth Service owns identity tables. Vault injects the Stripe key and JWT signing material.

Observability

Sentry captures frontend, API and worker errors. The DLQ is alert-only by design: a non-empty queue pages the owner instead of silently retrying forever.

Typical Bottlenecks

  • API throughput during tenant spikes
  • Background job backlog around billing cycles
  • PostgreSQL write pressure on high-cardinality events

Async Flow and Reliability

User actions stay fast on synchronous APIs while expensive work is queued to BullMQ and consumed by the worker service. Exhausted jobs land in the DLQ instead of disappearing, so failures are visible and replayable.

Upgrade Path

Start with one API service, one worker and PostgreSQL. Split billing, auth and reporting into independently deployable services once usage stabilises, then add read replicas for analytics traffic.