Exercise 3: Choosing Where to Deploy — Possible Solution
==========================================================

Decision note: deploying the blog API

Context
- Readers are mostly in one country.
- PostgreSQL runs in a region in that country.
- Traffic is steady with occasional spikes (a popular post).
- Every request reads from the database; most are simple lists and
  single posts.

Options considered

1. A single long-running container (with a second for redundancy),
   in the same region as the database.
   + One PrismaClient per process, predictable connections (Chapter 7).
   + Low latency to the database; no cold starts.
   + Simple Docker build, release step for migrations.
   - Pays for idle time; scaling is manual or needs autoscaling rules.

2. Serverless functions in the same region.
   + Scales automatically and costs little when idle.
   - Cold starts; connection multiplication during spikes, needing a
     pool of 1 per instance and ideally an external pooler.

3. Edge functions.
   + Close to readers.
   - Readers are already close to the database's region, so there's
     little latency to save, and every query would travel back to the
     database anyway. Also needs an edge-compatible driver.

Decision
Option 1: two containers in the database's region, behind a load
balancer, with migrate deploy as a release step.

Why
The audience and database are in the same place, so edge brings no real
benefit. Traffic is steady, which suits long-running servers, and
Prisma's connection handling is simplest there. Spikes are handled by
Chapter 7's query fixes and, if needed, a CDN cache for public pages.

Revisit if
- The audience becomes international (consider caching or read
  replicas nearer readers before moving logic to the edge).
- Traffic becomes very spiky or mostly idle (reconsider serverless,
  with an external pooler).

WHY THIS WORKS AS AN ANSWER
------------------------------
It ties the decision to the stated facts rather than to what's
fashionable. The key point from the chapter — distance to the database
matters more than distance to the user for database-heavy pages —
rules out edge. It records the trade-offs honestly and says what would
change the decision, which is what makes a decision note useful later.