# Scaling Nextdoor's Datastores: Part 4

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

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

Author: Ronak Shah

Published: 2025-03-19T15:08:57Z

Content type: article

Language: en

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

Topics: [Cache](<https://devfeed.tech/topics/cache.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [consistency](<https://devfeed.tech/topics/consistency.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [cache-control](<https://devfeed.tech/tags/cache-control.md>), [cache-invalidation](<https://devfeed.tech/tags/cache-invalidation.md>), [caching](<https://devfeed.tech/tags/caching.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [database](<https://devfeed.tech/tags/database.md>), [database-consistency](<https://devfeed.tech/tags/database-consistency.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [examples](<https://devfeed.tech/tags/examples.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [lua](<https://devfeed.tech/tags/lua.md>)

## AI overview

Part 4 of Nextdoor's datastore series explains how racing database writes can update a cache in a different order, allowing stale writes and leaving the cache inconsistent with the database. It introduces the problem and notes that the full solution will be covered in a later installment.

## Source excerpt

In this part of the Scaling Nextdoor's Datastores blog series, we will see how the Core-Services team at Nextdoor keeps its cache consistent with database updates and avoids stale writes to the cache. In this post, we'll focus specifically on inconsistencies caused by racing writes and our solution. We'll discuss other causes and our full solution for consistent caching in the next installment of our blog: Part 5: A time-bounded eventually-consistent cache. Inconsistent Cache Caches can become inconsistent with the database for several reasons, such as: Racing Writes / Concurrent Updates: Multiple writes occurring simultaneously can result in a stale cache. Missed Writes / Failing to Update the Cache: Failure to update or set cache correctly after a database write. Delayed Cache Updates or Deletes: Slow propagation of updates or invalidation can leave the cache out of sync. Application-Level Bugs: Bugs in application side caching logic. Maintaining cache consistency with the database is crucial for data accuracy, especially in distributed systems with concurrent web requests. Consistent caching ensures reliable read-after-write behavior, improving performance and user experience. Without it, applications may face unpredictable behavior and user frustration. A well-designed caching system boosts performance, ensures consistency, and delivers up-to-date data even under high concurrency. Racing Writes Let's look at the scenario where two writers, A and B, update the same user in the database but write to the cache in a different order, causing the cache to become inconsistent with the database. Author's Note: In examples moving forward we'll use "User_1" to mean id=1 in the "users" table.Look-Aside Cache with two writers. Sequence of operations: Writer A updates the name of user_1 to Foo in the database. Writer B updates the name of the same user_1 to Bar in the database. Writer B updates the cache for user_1 with name = Bar. Writer A updates the cache for user_1 with