BACKEND ENGINEERING / SERVER-SIDE DEVELOPMENT
PROPELOO engineers production backend systems — from API design and database modelling through authentication, background jobs, caching strategy and the observability that tells you what is actually happening at scale. The backend is not the boring part. It is the part that determines whether your product works when it matters.
Most backend systems fail under load for predictable reasons: no connection pooling (database connections exhausted at 500 concurrent users), synchronous processing of operations that should be async (API response time spikes when email sending is inline), missing indexes on query patterns that only become slow at production data volume, no caching layer so the same expensive query runs thousands of times per minute. These are not exotic failure modes — they are the ones we see in every backend review of a system that was built fast and never hardened for production. PROPELOO builds backends with the production failure modes modelled from the start: connection pooling configured, async jobs extracted, query plans reviewed and caching designed before the first user arrives.
REST APIs with OpenAPI spec, GraphQL with DataLoader (N+1 prevention), request validation with Zod/Joi, consistent error responses (RFC 7807) and API versioning strategy.
JWT with short expiry and refresh token rotation, OAuth 2.0 integration, RBAC at the service layer (not just the UI), session invalidation and audit logging for sensitive operations.
Schema design for access patterns, index strategy, query analysis with EXPLAIN, connection pooling via pgBouncer, read replicas for reporting queries, migrations with rollback.
Background job queues (BullMQ, pg-boss) for email, notifications, heavy processing. Message queues (SQS, Kafka) for service communication. Scheduled tasks with distributed locking.
Redis for session storage, rate limiting counters, expensive query results and computed values. Cache invalidation strategy per data type. Cache-aside vs read-through vs write-through selection.
Structured JSON logging with correlation IDs, OpenTelemetry distributed tracing, Prometheus metrics endpoints, Sentry error monitoring and p95/p99 latency dashboards.
The backend is a set of bets on access patterns and load characteristics. Get the bets wrong and you re-architecture under production pressure.
A database schema designed around domain entities ("what data do we have?") will have different performance characteristics than one designed around access patterns ("how will we query this data?"). The indexes that matter are the ones on columns that appear in WHERE clauses of frequent queries. Design the queries first, then the schema.
Axiom:
An API endpoint that sends an email, processes an image, calls three third-party APIs and updates five database tables while the user waits will have variable and unpredictable response times. Extract everything that does not need to happen before the response into background jobs. The endpoint returns in 50ms. The jobs process in seconds. The user experience is better.
Axiom:
A backend that makes the same expensive database query 10,000 times per minute will fail at scale regardless of hardware. Redis caching of expensive queries, computed aggregations and session state is not a performance optimisation to add later — it is an architectural decision that must be designed when the data access patterns are first understood.
Axiom:
PostgreSQL has a maximum connection limit (typically 100-200). Each Node.js process without a connection pool opens a new database connection per request. At 50 concurrent requests across 10 Node.js instances, you exhaust the connection limit. pgBouncer (connection pooler) or built-in connection pool configuration is not optional for production backends.
Axiom:
Impact: Node.js (TypeScript) for most API backends — ecosystem, developer availability and performance are sufficient for most workloads. Go for high-throughput microservices where latency and CPU efficiency matter. Python for backends tightly coupled to ML/data science.
Impact: REST for public-facing APIs. GraphQL when multiple clients (mobile, web, partner) need different data shapes. tRPC for TypeScript full-stack apps with shared types.
Impact: PostgreSQL for almost everything. Its JSONB support handles semi-structured data. Full-text search handles most search requirements. ACID transactions handle financial data. Only deviate with strong justification.
Impact: BullMQ for Node.js backends with Redis already in the stack. pg-boss for backends that want to avoid Redis dependency. Temporal for long-running multi-step workflows that must survive restarts.
Impact: Managed auth (Auth0, Clerk) for speed to market. JWT with refresh rotation for teams that want control. Session cookies for internal tools where stateless auth overhead is not worth it.
Impact: Redis cache-aside for session storage, rate limiting and expensive query results. CDN caching for public API responses with predictable staleness tolerance.
Node.js/Go REST API with OpenAPI spec, JWT auth, PostgreSQL, Redis caching, background jobs and production monitoring.
Apollo Server or Pothos GraphQL with DataLoader, subscriptions, persisted queries and complexity limiting.
Kafka or SQS-based event-driven architecture — producers, consumers, dead letter queues, retry logic and event schema registry.
Go backend engineered for 50K+ requests/second — connection pooling, read replicas, Redis caching and horizontal scaling.
Review of existing backend for N+1 queries, missing indexes, connection pool exhaustion, sync operations that should be async and missing observability.
Public API backend with OAuth 2.0, API key management, rate limiting, OpenAPI documentation, SDK generation and developer sandbox.
Stack: Node.js (TypeScript), Go, Python (FastAPI), Bun
Stack: Fastify, Express, Apollo GraphQL, tRPC, Hono
Stack: PostgreSQL, Redis, Prisma / Drizzle ORM, pgBouncer, pg-boss
Stack: BullMQ, Temporal, Kafka, AWS SQS, RabbitMQ
Stack: JWT (jose), Auth0, Clerk, Passport.js, Custom OAuth 2.0
Stack: OpenTelemetry, Sentry, Datadog, Prometheus, Pino (logging)
Parameterised queries — never string concatenation for SQL. ORM query builders (Prisma, Drizzle, Knex) use parameterised queries by default. Raw SQL must be reviewed carefully.
Validate all request inputs at the API boundary using Zod or Joi — string length, format, type, enum values. Reject unknown fields. Never trust client-provided data.
Per-API-key or per-IP rate limiting using Redis counters. Express-rate-limit, Fastify rate-limit or custom Redis middleware. Prevents brute force and DDoS without infrastructure changes.
Environment variables from AWS Secrets Manager or HashiCorp Vault at runtime. No credentials in source code. Pre-commit hooks scan for accidental secrets.
Explicit allow-list for CORS origins — not wildcard (*) for credential-bearing requests. Preflight caching headers for performance. Separate CORS config for public and authenticated endpoints.
Structured log entries for all authentication events (login, logout, token refresh, failed attempts), sensitive data access and admin operations. Logs to immutable store for security review.
OpenAPI spec written before implementation. Resource modelling, auth design, error taxonomy.
Project scaffold, database schema, migrations, auth middleware, CI pipeline.
Business logic endpoints with validation, error handling and unit tests.
Background job queue, scheduled tasks, email/notification workers.
Redis integration, query optimisation with EXPLAIN, connection pool tuning.
Structured logging, Sentry errors, OpenTelemetry tracing, latency dashboards.
k6 load test to expected peak, fix bottlenecks, production deployment.
Node.js for most product backends — large ecosystem (npm), TypeScript support, fast development, sufficient performance for most web APIs (handles 10K req/s on a single core with async I/O). Go for high-throughput services where latency and CPU efficiency matter — Go handles 50K-100K req/s on comparable hardware, with lower memory usage and better concurrency primitives. Choose Go when performance requirements are demonstrated, not anticipated.
N+1 queries occur when fetching a list (1 query) then fetching related data per item (N queries). Solutions: DataLoader for batching in GraphQL, eager loading with JOIN or ORM includes for REST, query analysis with pg_stat_statements in PostgreSQL. Every GraphQL resolver should use DataLoader. Every ORM query returning a list should specify which relations to include.
Message queues are justified when: processing must continue if the consumer is temporarily unavailable, processing is too slow for synchronous response (image processing, PDF generation), multiple services need to react to the same event, or traffic spikes must be absorbed without losing work. Common mistake: using message queues prematurely when a simple background job queue (BullMQ) would suffice.
Expand-contract pattern for zero-downtime migrations: expand (add new column/table without removing old), migrate application to use new structure, contract (remove old column/table after all instances use new structure). Never drop columns in the same migration as adding them — old application instances still reference them. Automated migration in CI (run on deploy), rollback scripts prepared and tested.