Blog Platform Read Replica Scaling
Moving list and analytics queries off the primary without stale content surprises.
Nestlancer Editorial

Moving list and analytics queries off the primary without stale content surprises. The team prioritized operational ownership while migrating on a Nestlancer-style stack—gateway at the edge, domain NestJS services, Prisma on Postgres, async work through RabbitMQ, and media on Backblaze B2.
Where we started
The team inherited public blog traffic hammering the primary Postgres during marketing launches. The triggering incident was clear: publish spikes slowed checkout writes on the shared cluster. Leadership funded the refactor when customer-visible latency and support load rose together—not when the diagram looked messy.
Architecture before
- Single deploy artifact coupling unrelated domains
- Synchronous cross-module HTTP with partial timeouts
- Mixed read/write traffic on one database primary
- Ad-hoc file storage complicating virus scan and CDN caching
Migration timeline
Discovery
Mapped public blog traffic hammering the primary Postgres during marketing launches and inventoried which routes could move behind the gateway without user-visible changes.
Strangler cutover
Routed new traffic through NestJS handlers while legacy paths drained over 10 weeks.
Reliability hardening
Added read replicas, Prisma, Redis with explicit SLOs owned by a 9-engineer platform squad.
Stabilize and learn
Ran game days for DLQ replay, replica lag failover, and presigned upload expiry edge cases.
Patterns we applied
- Read replicas via a dedicated Prisma read client served list and analytics traffic.
- Prisma migrations shipped expand/contract to avoid hard downtime windows.
- Redis guarded hot list endpoints without stale writes after publish events.
Code sketch from the cutover
@Controller('blog')
export class BlogGatewayController {
constructor(private readonly blogClient: BlogServiceClient) {}
@Get('posts')
list(@Query() query: ListPostsDto) {
return this.blogClient.listPosts(query);
}
}
Results
- routed list/detail reads to replicas; primary write latency stabilized
- On-call pages for queue backlog fell after outbox lag dashboards went live
- Product teams could ship blog and portfolio changes without redeploying payments
- Support tickets citing 'stale listings' dropped once read paths moved to replicas
Retrospective checklist
- Game day DLQ replay documented with ordering notes
- Replica lag runbook tested in staging monthly
- Presigned upload TTL aligned with mobile retry policy
- Gateway error envelope consistent across all domain services
- Post-incident templates link to dashboards—not screenshots
Lesson
Microservices did not arrive on day one. The team earned splits by proving operational ownership per domain—not by copying a reference diagram. The Nestlancer patterns above were adopted only after metrics justified the coordination cost.
Comments
Loading comments…
Related posts

Case Studies
Cutting Deploy Time from 45 Minutes to Five
CI caching, smaller artifacts, and service-level pipelines after monolith split.

Case Studies
Scaling a Freelance Marketplace Architecture
Matching algorithms, escrow flows, and dispute resolution at growing GMV.

Case Studies
GDPR Compliance Platform Rebuild
Data maps, deletion workflows, and consent logging across microservices.

Case Studies
Migrating from WebSockets to SSE
Simpler infra, CDN friendliness, and trade-offs for one-way realtime feeds.