# Scaling Nextdoor’s Datastores: Part 2

[Nextdoor](https://yomu.fyi/company/nextdoor) · Tushar Singla · Mar 19, 2025

**Type:** Problem & solution

## Summary

Nextdoor encountered scaling issues after adding read replicas when product engineers were initially tasked with deciding whether to route queries to the primary or replica databases. As business logic grew and gained abstraction layers, engineers struggled to track read-after-write consistency constraints across the call stack. To avoid replication lag race conditions, engineers routinely wrapped logic in database transactions, unintentionally directing all queries to the primary node and eroding read replica benefits over several years. The Core-Services team resolved this by injecting custom tracking logic into their Django ORM layer to monitor table writes during web requests and automate routing. They further optimized the system using a timing-based approach that restored replica read eligibility after the p99.9 replication lag elapsed.

## Context

Nextdoor introduced read replicas to manage rising database demand and initially relied on Django ORM routing features to let product engineers manually select primary or replica targets. As codebase abstractions increased, engineers faced read-after-write consistency bugs due to replication lag and began defaulting to primary transactions, which overloaded the primary database.

## Approach / What changed

Nextdoor built custom routing logic directly into their ORM to track modified tables within each web request and automatically route subsequent reads. They also implemented a timing-based system that re-enabled read replica routing for modified tables once the p99.9 replication lag duration passed, while cleaning up legacy manual routing and inappropriate transaction usage.

## Takeaways

- Manual query routing decisions by product engineers broke down as layered abstractions hid write and read operations across call stacks.
- Wrapping operations in transactions to avoid replication lag routed all enclosed queries to the primary, eroding replica capacity gains over years.
- Injecting table-modification tracking into the ORM and restoring replica eligibility after p99.9 replication lag successfully offloaded read traffic from the primary.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Performance](https://yomu.fyi/topic/performance), [Python](https://yomu.fyi/topic/python), [Scalability](https://yomu.fyi/topic/scalability)

[Read original post](https://engblog.nextdoor.com/scaling-nextdoors-datastores-part-2-513922e4b4b1)