Static-First Architecture for Sites That Serve 100M Visits
A static-first architecture serves every public page from an edge cache generated ahead of time, uses tag-based on-demand revalidation to refresh only the pages a change affects, and keeps the database out of the hot path entirely.
Serving a hundred million visits a month is not primarily a scaling-up problem. It is a don't-do-the-work problem.
The database is not in the hot path
On a well-designed content platform, cached public traffic never touches Postgres. The database is read only when a page is (re)generated — on publish, on update, or on a scheduled revalidation. Everything else is a cache HIT.
Tag-based revalidation
When an editor publishes a post, you do not rebuild the site. You revalidate exactly the tags that changed: the post itself, its category and tag archives, the homepage, the feeds, and the affected sitemap shard. Everything else stays warm.
Sharded sitemaps
A single sitemap maxes out at 50,000 URLs. Shard into files of 10,000, expose an index, and regenerate individual shards through the same tag-revalidation mechanism.
Stateless everything
Application containers hold no session state. Queues live in a shared broker, media lives in object storage behind a CDN, and any container can serve any request. That is what makes horizontal scaling boring — which is exactly what you want.
Frequently asked questions
- Should public pages ever query the database directly?
- No. Public pages should be served from an edge cache. The database is queried only during generation or revalidation, never on a cache HIT.