Part 3 · Lesson 13 · Advanced

Databases: Where State Lives

Give your stateless app one place that remembers.

In this interactive Infrastructure lesson from Stencel Academy you don't just read — you type real commands like psql -h db-01 -c "SELECT email FROM users LIMIT 3;", psql -h db-01 -c "UPDATE users SET plan='pro' WHERE id=42;" and watch the machine respond on a live, animated map. It is part of the free How Infrastructure Works course.

Key takeaway: Apps stay stateless so the database can be the one place that remembers — and replicas keep a live copy.

Before this lesson

Builds on: Web Servers & Reverse Proxies.

What you'll practise

psql -h db-02 -c "SELECT pg_is_in_recovery();" — Ask db-02 what it is: t = replica.
psql -h db-02 -c "UPDATE users SET plan='pro' WHERE id=42;" — Writes to a replica fail — one writer keeps one truth.
psql -h db-01 -c "SELECT client_addr, state FROM pg_stat_replication;" — The primary knows who is following it.
pg_dump -h db-01 promptd | head -5 — A backup is the state, serialized — replicas are not backups.

Terms you'll learn

primary / replicareplicationWAL (write-ahead log)SQLcommit

Check your understanding

Why do web-01 and web-02 run promptd stateless?

So all state lives in one database, and any backend can serve any request
Because PostgreSQL refuses connections from apps that keep local state
Stateless processes use less CPU than stateful ones

Open the interactive lesson →