Scaling Nextdoor’s Datastores: Part 1

Summary

Nextdoor relies on a Django backend connected to monolithic PostgreSQL databases and Redis look-aside caches. Migrating to distributed SQL datastores proved impractical because legacy business logic depends heavily on multi-table joins that could not be rewritten. Intermediate mitigations, including read replicas and data partitioning by severing foreign keys, extended infrastructure runways but left primary databases vulnerable to load bottlenecks. Furthermore, look-aside caching and replica usage introduced data staleness risks, atomicity losses across partitioned databases, and inconsistent cache-population behaviors. To address these limitations, Nextdoor initiated an architecture redesign focused on dynamic query routing to replicas, replica-driven cache hydration, time-bounded eventual consistency, and schema-resilient cache serialization.

Takeaways

1. 1

   Adopting distributed SQL datastores can be blocked when entrenched application codebases rely heavily on multi-table joins across monolithic relational models.

2. 2

   Partitioning databases by severing foreign-key relationships extends scaling runway but can subtly break transactional atomicity during successive writes across databases.

3. 3

   Querying the primary database during a cache miss does not guarantee that the value written to the cache reflects the most up-to-date data.