Skip to main content
← Back to articles

Blog Platform Read Replica Scaling

Moving list and analytics queries off the primary without stale content surprises.

Nestlancer Editorial

Share

Blog Platform Read Replica Scaling

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