Back to path
MediumWorking system ~17h· 5 milestones

Build a service with a real database, caching, and limits

A service that’s correct but slow (or falls over under load) is a real on-call problem. You build one that holds up: a sensible schema, no N+1s, caching, rate limiting, and idempotent writes.

Data modelingMigrationsQuery optimization (N+1)Caching (Redis)Rate limitingIdempotencyObservabilityCost modelingIncident runbook
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

A backend service over a real database with migrations, query optimization, a caching layer, rate limiting, idempotent endpoints, and metrics.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

docker-compose.ymlyaml
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: posts
    ports: ["5432:5432"]
  redis:
    image: redis:7
    ports: ["6379:6379"]

Reading this file

  • image: postgres:16Pins a specific Postgres version so everyone on the team runs the same database locally.
  • POSTGRES_PASSWORD: appSets dev credentials via env vars, fine for local only, never commit real secrets like this.
  • ports: ["5432:5432"]Maps the container's database port to your machine so your app can connect on localhost.
  • image: redis:7Runs Redis alongside Postgres so you can build the caching and rate-limiting layers locally.

One command to get a real Postgres + Redis locally.

That's 1 of 9 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Model the data

    5 guided steps

    The schema is the foundation everything else sits on. Getting normalization, keys, and indexes right early prevents the painful migrations and slow queries that haunt a service later.

  2. 2

    Kill the N+1s

    5 guided steps

    N+1 queries are the most common backend performance bug, a list endpoint that quietly fires hundreds of queries. Finding and fixing them is a core backend skill interviewers probe for.

  3. 3

    Add caching & limits

    5 guided steps

    Caching turns repeated expensive reads into microseconds, and rate limiting protects the service from abuse and runaway clients. Both are everyday production necessities.

  4. 4

    Make writes safe

    5 guided steps

    Networks retry. Without idempotency, a retried "create payment" charges twice. Idempotency keys are how real systems make writes safe to retry.

  5. 5

    Operate it: dashboards, cost & a runbook

    5 guided steps

    Metrics nobody graphs and a service nobody has costed or written runbooks for is what on-call dreads. This milestone turns raw numbers into something operable at 3am.

What's inside when you start

4 starter files, ready to clone
5 guided milestones
5 full reference solutions
9 code blocks explained line-by-line
5 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A service repo with migrations and a load/perf note
Before/after query metrics showing the N+1 fix
A demonstration that a retried write with the same idempotency key has no double effect
A metrics dashboard with SLO-based alerts and a $/1M-requests cost report naming the cost driver
A runbook for the top three failure modes with first mitigations

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building