Skip to content

Upcoming Content

Backend engineering doesn't end at REST APIs and PostgreSQL — there's a whole ecosystem of patterns , protocols , and platforms that separate "I can build an API" from "I can design distributed systems" This section covers the topics you're gonna need when your monolith starts feeling tight , your WebSocket connections pile up , and someone asks "should we use GraphQL?" in a sprint planning meeting

What's Coming

These aren't academic exercises — every topic here solves a real problem you'll hit as your backend grows beyond the basic CRUD pattern

The Lineup — What , Why , When

GraphQL

When your React frontend needs user profile , recent orders , and notification count all on one screen , REST makes you fire 3-4 requests or maintain a separate "dashboard" endpoint that breaks every time the UI changes GraphQL inverts the problem: the frontend describes exactly what it needs and the backend fetches it in one round trip. The cost? Your resolvers need to be efficient , your queries need depth limits , and your monitoring needs to catch expensive queries before they crater your database

WebSockets

Your users expect real-time by default — messages delivered instantly , notifications that don't require a page refresh , live dashboards that update as data arrives HTTP was designed for documents , not streaming. WebSockets give you persistent bidirectional channels where either side can push data at any time. The challenge shifts from "how do I send data" to "how do I scale 10k concurrent connections and broadcast to rooms efficiently"

Microservices

The tipping point is different for every team — maybe it's deploy coupling (a 3-line change requires full redeploy) , team coordination (15 people PRing into the same repo) , or scaling (search needs 10 instances , auth needs 2 , but they share a process) Microservices let each service scale , deploy , and evolve independently. They also introduce distributed systems nightmares: service discovery , eventual consistency , network failures , debugging across 10 services

Serverless

For event-driven workloads (processing uploads , responding to webhooks , running scheduled jobs) , managing EC2 instances is overkill Lambda and its competitors abstract the server entirely — you write a function , configure a trigger , and AWS handles the rest. Cold starts , function timeouts , and stateless design constraints are the tradeoffs you accept for zero infrastructure management

Message Queues

Any request that takes more than a few hundred milliseconds shouldn't block the HTTP response Message queues decouple request acceptance from request processing. Your API returns 202 Accepted immediately , a worker picks up the job when it can , and the user gets notified when it's done. This pattern applies to email sending , report generation , image processing , and anything that doesn't need to happen synchronously

What's Next

Bun , Deno , Edge computing , WebAssembly , CRDTs , AI integration — these aren't sci-fi , they're running in production today The backend landscape is fragmenting into specialized runtimes and compute models. Understanding where each fits helps you make better architecture decisions when the next hype cycle hits

Prerequisites

All of DevOps section , Node.js section , Express section

Each topic assumes you can: * Build and deploy a REST API with Express * Use Docker for local development * Set up a basic CI pipeline * Debug production issues with logs and metrics

If any of that feels shaky , go back through the main curriculum before diving in here

What NOT to Do

  • Don't adopt GraphQL just because it's trendy — if REST is working , you're adding complexity without benefit
  • Don't split microservices before you need to — the overhead of inter-service communication , deployment pipelines , and debugging across services will slow you down more than the monolith ever did
  • Don't use serverless for long-running stateful workloads — Lambda has a 15-minute timeout and no local filesystem persistence
  • Don't use message queues for request-response patterns — that's what load balancers and worker pools are for
  • Don't chase the shiny new runtime for an existing production system — let the new tools prove themselves first

How to Use This Section

  • Read in order — topics build on each other
  • Each page has runnable code examples — don't just read , actually spin them up
  • The "when to use this" sections matter more than the syntax
  • If a topic seems irrelevant to your current work , skim it and come back when you need it
  • Each page ends with production considerations — read those even if you skip the code

How to Use This Section

  • Read in order — topics build on each other
  • Each page has runnable code examples — don't just read , actually spin them up
  • The "when to use this" sections matter more than the syntax
  • Repos linked where relevant — clone , run , break , fix

next → upcoming_01_graphql.md