How I Built My Blog to Scale (Before It Needed To)
The architecture decisions I made upfront — ISR, DB indexes, cursor pagination, and Redis caching — to keep my Next.js blog fast without over-engineering it.
Most blog tutorials get you live fast — but fall apart under real traffic. Here's how I structured mine to handle scale before it was a problem, without building things I don't need yet.
Rendering First
The biggest win is picking the right rendering strategy per page type. Post list and individual posts use ISR and SSG — they're cached at the CDN edge and revalidate automatically. Search and filters use SSR since they can't be pre-rendered. The admin dashboard is pure CSR — no SEO needed there anyway.
Database Indexes Early
I added three indexes to the Prisma schema upfront: publishedAt, category, and a compound (status, publishedAt) for the most common list queries. Slug is already indexed via @unique. Pagination is cursor-based — never fetching all posts at once.
Schema Built for Tomorrow
The Post model includes a status enum (DRAFT, PUBLISHED, ARCHIVED), updatedAt via @updatedAt, a views counter ready to activate, and a category enum. No extra tables, no premature normalization — just fields I'll actually use.
Caching Layer
Static pages deploy to Vercel's edge network. Repeated DB queries (like posts by category) are cached via Upstash Redis. Images go through Next.js <Image> for automatic optimization.
What I Skipped
No message queues, no read replicas, no microservices. Those get built when traffic demands them — not before.
The priority order that actually worked: ISR/SSG → CDN → DB indexes → Schema → Redis → API hardening.