# Scaling Nextdoor's Datastores: Part 5

DevFeed: [Scaling Nextdoor's Datastores: Part 5](<https://devfeed.tech/articles/scaling-nextdoor-s-datastores-part-5-20344.md>)

Original publisher: [Read original article](<https://engblog.nextdoor.com/scaling-nextdoors-datastores-part-5-5221da60f374?source=rss----5e54f11cdfdf---4>)

Author: Slava Markeyev

Published: 2025-03-19T15:09:15Z

Content type: article

Language: en

Sources: [Nextdoor](<https://devfeed.tech/sources/nextdoor.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [consistency](<https://devfeed.tech/topics/consistency.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [Usability](<https://devfeed.tech/topics/usability.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [cache-invalidation](<https://devfeed.tech/tags/cache-invalidation.md>), [caching-strategies](<https://devfeed.tech/tags/caching-strategies.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [database-consistency](<https://devfeed.tech/tags/database-consistency.md>), [database-scalability](<https://devfeed.tech/tags/database-scalability.md>), [databases](<https://devfeed.tech/tags/databases.md>), [rdbms](<https://devfeed.tech/tags/rdbms.md>), [reconciliation](<https://devfeed.tech/tags/reconciliation.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [stream](<https://devfeed.tech/tags/stream.md>), [usability](<https://devfeed.tech/tags/usability.md>)

## AI overview

The final installment of Nextdoor's datastore-scaling series explains how cache consistency can fail when a database writer misses its cache update. It presents a Change Data Capture stream and a reconciler that uses database changes to repair cache inconsistencies.

## Source excerpt

In this final installment of the Scaling Nextdoor's Datastores blog series, we detail how the Core-Services team at Nextdoor solved cache consistency challenges as part of a holistic approach to improve our database and cache scalability and usability. In Part 4: Keeping the cache consistent, we highlighted a class of consistency issues arising from racing cache writes and introduced an approach for forward cache versioning as a mechanism to avoid inconsistencies. The cache is able to decide which write to persist and which to reject because it is aware of the version of data it currently has. However, this is only a partial solution because it assumes writers will always succeed in communicating with the cache in a timely manner, if at all. Missed Writes Let's consider the scenario where Writers A and B both performed an update to the same row in the database and have not yet updated the cache. Writer A holds Version 1 and Writer B holds Version 2. What happens if Writer B with Value 2 fails to talk with the cache? Writer B fails to write to the cache. In this case the result is that the cache becomes inconsistent and we can't rely on the writers to provide that consistency. A process must exist outside of this interaction to fix-up the cache when Version 2 is written to the database but fails to be written to the cache. Change Data Stream To solve this problem we tap into a common feature provided by most modern databases, a Change Data Capture (CDC) Stream. A CDC Stream is a mechanism to subscribe to row level changes in a database. The change stream contains a row's previous column values along with the new values. Here's a visual example of the change stream when the last_name field gets updated in the database. For visual clarity the changed values have been underlined in red. Reconciler Since the database is the source of truth and the CDC Stream emits all changes, a consumer of this stream can clean up any consistency issues in the cache. In our system we ca