Backend Components
A walk from the user's keystroke to the database row and back, naming every component the packet passes through.
1. DNS
Names become addresses. The user types topliving.com.co; their resolver
(typically their OS, talking to their ISP or 1.1.1.1) walks the DNS tree from the root,
to .co, to topliving.com.co, until it gets an A or AAAA record
with an IP.
Record types worth knowing:
- A — name → IPv4.
- AAAA — name → IPv6.
- CNAME — alias from one name to another.
- MX — mail server for the domain.
- TXT — free text, used for SPF, DKIM, verification.
- NS — which servers are authoritative for the zone.
See DNS Record Types (sub-deck).
2. CDN / Edge
For most requests, the closest CDN node responds. Static assets, cached pages, and increasingly compute (edge functions) live here. The request only reaches your origin if the CDN can't answer.
3. Load balancer
Layer-4 (TCP) or Layer-7 (HTTP). Distributes traffic across application instances using a strategy: round-robin, least-connections, IP-hash, or weighted. Also terminates TLS so application servers can speak plain HTTP internally.
4. Application server
Where your code runs. Frameworks: Flask/FastAPI (Python), Express (Node), Spring Boot (Java), Rails (Ruby). Behind it usually sits a process manager (gunicorn, uvicorn, pm2) that runs N workers.
5. Cache
An in-memory store sitting between the app and the database. Redis, Memcached. Caches anything expensive to recompute: query results, sessions, rate-limit counters.
The hard part is invalidation. Strategies:
- TTL — entries expire after N seconds. Simple, slightly stale.
- Write-through — every DB write also writes the cache.
- Cache-aside — read tries cache; on miss, reads DB and populates cache.
6. Database
Relational (Postgres, MySQL) vs document (MongoDB) vs key-value (Redis) vs columnar (BigQuery, ClickHouse). The choice is driven by the access pattern, not by fashion.
Relational defaults are still the right answer for most apps. ACID guarantees, mature tooling, joins. Pick something else when you have a concrete reason: planet-scale, write-heavy time series, or schema that genuinely doesn't fit rows and columns.
7. Message broker / Queue
RabbitMQ, Kafka, SQS, Redis streams. Decouples producers from consumers. Producer publishes an event; one or more consumers process it asynchronously.
Use when:
- The work is too slow to keep the user waiting (sending an email, generating a PDF, processing an image).
- You want retries and dead-letter handling out of the box.
- You need an audit log of every event that crossed the system.
8. Object storage
S3, GCS, R2. Anything binary that isn't a database row: user uploads, generated artifacts, backups. Cheap, durable, eventually consistent.
A request, end to end
User clicks "search". Browser → DNS → CDN (miss) → LB → App server (Flask) → Redis (miss) → Postgres (returns rows) → App formats JSON → response back through LB to user. Total: ~80 ms. Anything slower is a problem to investigate.
What to remember at exam time
- The eight components above, in order, and what each does.
- Six DNS record types.
- Cache invalidation strategies — TTL, write-through, cache-aside.
- "Sync vs async" — when to put a queue in front of work.