Scenario / The monolith
Request-Response Basics: Your First Backend Architecture
Simple project management tool. Steady traffic, modest scale. Your first real deployment.
Run this scenarioBriefing
Request-response fundamentals
A request-response system handles one user action by routing it through an application server and, usually, a database before returning a response.
Most backend architectures start here. If the basic path has no spare capacity, every later feature inherits that fragility.
The simplest architecture is also the most fragile: one server, one database, no safety net.
- Start with the minimum viable stack: one server and one database.
- Watch whether server or database pressure rises first as traffic increases.
- Treat latency as an early warning before errors appear.
Contract
99%
400ms
$300/mo
Traffic shape
Daily traffic curve with a predictable high-traffic window. Baseline 45 users; peak around 320 users over 36 hours.
Available components
Server
HTTP request handler Every web app needs at least one server. More servers let you handle more simultaneous requests before latency starts climbing.
Postgres
Primary data store Without a database, your app has no memory. Most dynamic requests eventually depend on it.
Common mistakes
- Rolling recovery preserves availability better than restarting the whole fleet.
- Cost optimization should follow measured bottlenecks, not gut feel.
Interview adjacency
- Design a URL shortener
- Design a simple web app
- Explain request-response flow