- Keep long-running tasks outside the request path
- Centralize error handling and configuration
- Use caching for repeat-access paths
- Trace request and service behaviour with OpenTelemetry
Case study 02 / Backend Engineering · System Design
An API designed for production workloads.
A Node.js backend architecture that separates application logic, data persistence, caching, asynchronous processing and observability instead of stopping at CRUD.
Project
Production REST API Architecture
My role
Backend architecture, implementation and infrastructure design
Production-oriented backend
ClientHTTP request
Express REST APIRoutes · Middleware · Validation
Service LayerBusiness logic
PostgreSQLPrisma · Persistence
RedisCache · Fast reads
BullMQAsync queue
Background worker
OpenTelemetry tracing + observabilityDocker application + infrastructure packaging
01 / The challenge
Start with the problem.
A basic CRUD API is easy to start but becomes difficult to operate when persistence, caching, background work, observability and infrastructure concerns are mixed into the same application flow.
Business requirement
Design a backend foundation that can support SaaS platforms, CRM integrations, internal business APIs and data-intensive workloads while allowing infrastructure components to evolve independently from request-handling code.
02 / The approach
Connect the moving parts.
- 01
Built the API layer with Node.js, Express and TypeScript, keeping routes, middleware and service logic separated.
- 02
Used PostgreSQL with Prisma for structured persistence and Redis for high-performance cached access.
- 03
Moved asynchronous work into BullMQ queues and background workers instead of blocking API requests.
- 04
Added OpenTelemetry as the observability layer and Docker-based infrastructure for a repeatable runtime environment.
Client
Express API
Services
PostgreSQL / Redis / BullMQ
03 / Engineering decisions
The thinking behind the work.
Separate application and infrastructure concerns
Routes, services, middleware, queues and infrastructure are kept distinct so a change in one area does not force the entire backend to be redesigned.
Use the right data path for the workload
PostgreSQL remains the structured source of truth while Redis handles cacheable reads and BullMQ handles work that should not extend request latency.
Make observability part of the architecture
OpenTelemetry is included as a first-class layer so tracing and operational visibility are considered before production incidents happen.
04 / Ownership
What I implemented.
API and service-layer structureDatabase and Prisma integrationRedis caching patternBullMQ queue and worker integrationCentralized configuration and error handlingDocker-based local infrastructure
05 / Production thinking
Reliability before scale.
- Keep environment-specific configuration outside application code
- Validate request boundaries before business logic
- Keep data-access and queue concerns behind service interfaces
06 / Engineering evidence
What a reviewer can inspect.
Repository
Source code is published publicly so the project structure, API separation and infrastructure choices can be reviewed directly.
Architecture
The design shows synchronous request handling, persistent data, cache access and asynchronous processing as separate responsibilities.
Production concerns
Observability, centralized errors and Docker infrastructure are part of the project rather than being treated as later add-ons.
07 / The outcome
What changed.
A backend reference architecture focused on the components that become important as an application moves from a CRUD prototype toward production business workloads.