In the world of software development, caching is often introduced as a performance optimization technique. And indeed, when implemented correctly, caching can dramatically improve application response times, reduce database load, and enhance user experience. However, what many developers discover the hard way is that caching introduces a fundamental challenge: data consistency.<\/p>\n
If you’ve noticed strange behaviors in your application where data seems outdated, inconsistent across different parts of your system, or mysteriously “flickering” between old and new values, your caching strategy might be the culprit. This comprehensive guide will help you understand why caching can lead to data consistency issues and provide practical solutions to address these challenges.<\/p>\n
At its core, caching is simple: store a copy of data in a location that’s faster to access than the original source. However, this simplicity belies the complexity that arises when the original data changes.<\/p>\n
When we cache data, we’re making an explicit tradeoff between consistency and performance. The CAP theorem tells us that in distributed systems, we can have at most two of the following three properties:<\/p>\n
Since network partitions are a reality we must deal with, the real choice becomes one between consistency and availability. Caching typically pushes us toward availability at the expense of consistency.<\/p>\n
Different caching approaches present different consistency challenges:<\/p>\n
Each of these approaches creates its own set of consistency considerations. An in-memory cache in a single-server application might have simpler consistency requirements than a globally distributed system using CDNs and multiple caching layers.<\/p>\n
Let’s explore the most common consistency issues that arise in cached systems:<\/p>\n
This is the most obvious issue: a cache contains outdated information that no longer reflects the source of truth. For example, a product price is updated in the database, but users still see the old price because it’s cached.<\/p>\n
\/\/ Example of potential stale data issue\nfunction getProductPrice(productId) {\n \/\/ Check if price is in cache\n const cachedPrice = cache.get(`product:${productId}:price`);\n \n if (cachedPrice) {\n return cachedPrice; \/\/ This could be stale!\n }\n \n \/\/ If not in cache, get from database\n const price = database.getProductPrice(productId);\n \n \/\/ Store in cache for 1 hour\n cache.set(`product:${productId}:price`, price, 3600);\n \n return price;\n}\n<\/code><\/pre>\nIn this example, if the price changes in the database, it won’t be reflected in the application until the cache expires or is manually invalidated.<\/p>\n
Cache Stampede (Thundering Herd)<\/h3>\n
When a frequently accessed cache key expires, multiple concurrent requests might attempt to rebuild the cache simultaneously, potentially overwhelming the backend system.<\/p>\n
\/\/ Vulnerable to cache stampede\nasync function getUserProfile(userId) {\n const cacheKey = `user:${userId}:profile`;\n \n \/\/ Check cache first\n const cachedProfile = await cache.get(cacheKey);\n if (cachedProfile) return JSON.parse(cachedProfile);\n \n \/\/ Cache miss - fetch from database\n \/\/ If 100 requests hit this simultaneously, we'll make 100 identical DB queries!\n const profile = await database.getUserProfile(userId);\n \n \/\/ Store in cache\n await cache.set(cacheKey, JSON.stringify(profile), 300);\n \n return profile;\n}\n<\/code><\/pre>\nWrite-Behind Inconsistency<\/h3>\n
In write-behind caching patterns, where updates are first made to the cache and asynchronously written to the database, failures in the background write process can lead to data loss or inconsistency.<\/p>\n
\/\/ Write-behind caching with potential consistency issues\nasync function updateUserPreferences(userId, preferences) {\n const cacheKey = `user:${userId}:preferences`;\n \n \/\/ Update cache immediately\n await cache.set(cacheKey, JSON.stringify(preferences));\n \n \/\/ Schedule background update to database\n backgroundQueue.push({\n task: 'updateUserPreferences',\n data: { userId, preferences }\n });\n \n return { success: true }; \/\/ Returns before DB is updated!\n}\n<\/code><\/pre>\nIf the background task fails, the cache and database will contain different data.<\/p>\n
Read-After-Write Inconsistency<\/h3>\n
Users expect that after they update data, they’ll see their changes reflected immediately. With caching, this isn’t always guaranteed.<\/p>\n
\/\/ Example of read-after-write inconsistency\nasync function updateUserProfile(userId, profileData) {\n \/\/ Update in database\n await database.updateUserProfile(userId, profileData);\n \n \/\/ User profile is cached, but we don't update the cache!\n \/\/ The next read will return stale data\n \n return { success: true };\n}\n\nasync function getUserProfile(userId) {\n const cacheKey = `user:${userId}:profile`;\n \n \/\/ Check cache first\n const cachedProfile = await cache.get(cacheKey);\n if (cachedProfile) return JSON.parse(cachedProfile);\n \n \/\/ Cache miss - fetch from database\n const profile = await database.getUserProfile(userId);\n \n \/\/ Store in cache\n await cache.set(cacheKey, JSON.stringify(profile), 3600);\n \n return profile;\n}\n<\/code><\/pre>\nAfter calling updateUserProfile<\/code>, the user would still see their old profile data if they immediately refresh the page.<\/p>\nCache Coherence in Distributed Systems<\/h3>\n
In systems with multiple application servers, each with its own local cache, updates made on one server may not be reflected in the caches of other servers.<\/p>\n
\/\/ Server A\napp.post('\/update-status', (req, res) => {\n const { userId, newStatus } = req.body;\n \n \/\/ Update in database\n database.updateUserStatus(userId, newStatus);\n \n \/\/ Update local cache for Server A\n localCache.set(`user:${userId}:status`, newStatus);\n \n res.json({ success: true });\n});\n\n\/\/ Server B - still has old status in its local cache!\napp.get('\/user-status\/:userId', (req, res) => {\n const { userId } = req.params;\n \n \/\/ Check local cache first\n const cachedStatus = localCache.get(`user:${userId}:status`);\n if (cachedStatus) {\n return res.json({ status: cachedStatus }); \/\/ This is stale!\n }\n \n \/\/ Otherwise fetch from database\n const status = database.getUserStatus(userId);\n localCache.set(`user:${userId}:status`, status);\n \n res.json({ status });\n});\n<\/code><\/pre>\nHow to Identify Caching-Related Consistency Problems<\/h2>\n
Before you can fix cache consistency issues, you need to identify them. Here are some signs and methods to diagnose caching problems:<\/p>\n
Common Symptoms<\/h3>\n\n- Users reporting they don’t see their own updates<\/li>\n
- Data appearing to “flicker” between old and new values<\/li>\n
- Inconsistent results when calling the same API multiple times<\/li>\n
- Data discrepancies between different parts of your application<\/li>\n
- Issues that “fix themselves” after a certain period<\/li>\n<\/ul>\n
Diagnostic Techniques<\/h3>\n
Add Cache Headers to Responses<\/strong><\/p>\nFor HTTP-based caching, include cache-related headers in your responses to help with debugging:<\/p>\n
\/\/ Express.js example\napp.get('\/api\/product\/:id', (req, res) => {\n const { id } = req.params;\n const product = getProduct(id);\n \n \/\/ Add cache debugging headers\n res.set('X-Cache', cache.has(id) ? 'HIT' : 'MISS');\n res.set('X-Cache-Expires', new Date(Date.now() + cacheTTL * 1000).toISOString());\n \n res.json(product);\n});\n<\/code><\/pre>\nImplement Cache Logging<\/strong><\/p>\nAdd detailed logging around cache operations:<\/p>\n
function getCachedData(key) {\n const startTime = Date.now();\n const value = cache.get(key);\n const duration = Date.now() - startTime;\n \n if (value) {\n logger.debug({\n message: 'Cache hit',\n key,\n duration,\n valueSize: JSON.stringify(value).length\n });\n return value;\n }\n \n logger.debug({\n message: 'Cache miss',\n key,\n duration\n });\n \n \/\/ Fetch and cache the data...\n}\n<\/code><\/pre>\nImplement Version Tagging<\/strong><\/p>\nAdd version information to your cached data:<\/p>\n
function cacheUserData(userId, userData) {\n const wrappedData = {\n data: userData,\n version: userData.version || Date.now(),\n cachedAt: new Date().toISOString()\n };\n \n cache.set(`user:${userId}`, JSON.stringify(wrappedData));\n}\n<\/code><\/pre>\nThis makes it easier to identify when you’re dealing with stale data.<\/p>\n
Cache Invalidation Strategies<\/h2>\n
The famous quote “There are only two hard things in Computer Science: cache invalidation and naming things” exists for a reason. Let’s explore different cache invalidation strategies:<\/p>\n
Time-Based Expiration<\/h3>\n
The simplest approach is to set a Time-To-Live (TTL) for cached items:<\/p>\n
\/\/ Set cache with a 5-minute TTL\ncache.set('user:1234', userData, 300);\n<\/code><\/pre>\nPros:<\/p>\n
\n- Simple to implement<\/li>\n
- Works well for data that changes predictably<\/li>\n
- No additional logic needed for invalidation<\/li>\n<\/ul>\n
Cons:<\/p>\n
\n- Data can be stale for up to the TTL duration<\/li>\n
- Hard to find the right TTL value (too short = cache ineffective, too long = stale data)<\/li>\n
- Can’t handle immediate invalidation needs<\/li>\n<\/ul>\n
Write-Through Caching<\/h3>\n
Update the cache whenever you update the underlying data:<\/p>\n
async function updateUserProfile(userId, profileData) {\n \/\/ Update in database\n await database.updateUserProfile(userId, profileData);\n \n \/\/ Update in cache\n const cacheKey = `user:${userId}:profile`;\n await cache.set(cacheKey, JSON.stringify(profileData));\n \n return { success: true };\n}\n<\/code><\/pre>\nPros:<\/p>\n
\n- Cache is always up-to-date<\/li>\n
- Solves read-after-write inconsistency<\/li>\n
- Conceptually simple<\/li>\n<\/ul>\n
Cons:<\/p>\n
\n- Requires updating cache on every write operation<\/li>\n
- Doesn’t handle distributed caching well without additional mechanisms<\/li>\n
- Can increase write latency<\/li>\n<\/ul>\n
Cache-Aside (Lazy Loading)<\/h3>\n
Load data into the cache only when it’s requested, and invalidate the cache when data changes:<\/p>\n
async function getUserProfile(userId) {\n const cacheKey = `user:${userId}:profile`;\n \n \/\/ Check cache first\n const cachedProfile = await cache.get(cacheKey);\n if (cachedProfile) return JSON.parse(cachedProfile);\n \n \/\/ Cache miss - fetch from database\n const profile = await database.getUserProfile(userId);\n \n \/\/ Store in cache\n await cache.set(cacheKey, JSON.stringify(profile), 3600);\n \n return profile;\n}\n\nasync function updateUserProfile(userId, profileData) {\n \/\/ Update in database\n await database.updateUserProfile(userId, profileData);\n \n \/\/ Invalidate cache\n const cacheKey = `user:${userId}:profile`;\n await cache.delete(cacheKey);\n \n return { success: true };\n}\n<\/code><\/pre>\nPros:<\/p>\n
\n- Only caches data that’s actually requested<\/li>\n
- Simple invalidation on write<\/li>\n
- Works well for read-heavy workloads<\/li>\n<\/ul>\n
Cons:<\/p>\n
\n- First request after invalidation is slow<\/li>\n
- Can lead to cache stampedes<\/li>\n
- Requires careful tracking of which keys to invalidate<\/li>\n<\/ul>\n
Event-Based Invalidation<\/h3>\n
Use events or message queues to notify all application instances when data changes:<\/p>\n
\/\/ When data changes\nasync function updateProduct(productId, productData) {\n \/\/ Update in database\n await database.updateProduct(productId, productData);\n \n \/\/ Publish event\n await messageQueue.publish('product-updated', {\n productId,\n timestamp: Date.now()\n });\n \n return { success: true };\n}\n\n\/\/ In each application instance\nmessageQueue.subscribe('product-updated', (message) => {\n const { productId } = message;\n \n \/\/ Invalidate local cache\n cache.delete(`product:${productId}`);\n \n console.log(`Cache invalidated for product ${productId}`);\n});\n<\/code><\/pre>\nPros:<\/p>\n
\n- Works well in distributed environments<\/li>\n
- Can provide near-real-time invalidation<\/li>\n
- Decouples cache invalidation from write operations<\/li>\n<\/ul>\n
Cons:<\/p>\n
\n- More complex infrastructure required<\/li>\n
- Potential for missed events if the message system fails<\/li>\n
- Can introduce additional latency<\/li>\n<\/ul>\n
Consistency Patterns and Solutions<\/h2>\n
Let’s explore some patterns that can help maintain data consistency in cached systems:<\/p>\n
The Stale-While-Revalidate Pattern<\/h3>\n
This pattern serves stale content while fetching fresh content in the background:<\/p>\n
async function getData(key) {\n const cached = await cache.get(key);\n \n if (cached) {\n const { data, timestamp } = JSON.parse(cached);\n const isStale = Date.now() - timestamp > STALE_THRESHOLD;\n \n if (isStale) {\n \/\/ Return stale data but refresh in background\n refreshDataInBackground(key);\n }\n \n return data; \/\/ Return potentially stale data immediately\n }\n \n \/\/ Cache miss - fetch fresh data\n return await fetchAndCacheData(key);\n}\n\nasync function refreshDataInBackground(key) {\n try {\n \/\/ Fetch fresh data\n const freshData = await fetchFromSource(key);\n \n \/\/ Update cache\n await cache.set(key, JSON.stringify({\n data: freshData,\n timestamp: Date.now()\n }));\n } catch (error) {\n logger.error(`Background refresh failed for ${key}`, error);\n }\n}\n<\/code><\/pre>\nThis pattern provides a good balance between performance and freshness.<\/p>\n
Two-Phase Commit for Cache Updates<\/h3>\n
For critical operations where consistency is paramount:<\/p>\n
async function updateCriticalData(key, newValue) {\n \/\/ Phase 1: Prepare\n const transactionId = generateUniqueId();\n await cache.set(`transaction:${transactionId}`, JSON.stringify({\n key,\n newValue,\n status: 'pending'\n }));\n \n try {\n \/\/ Phase 2: Commit to database\n await database.update(key, newValue);\n \n \/\/ Phase 3: Update cache and mark transaction complete\n await Promise.all([\n cache.set(key, JSON.stringify(newValue)),\n cache.set(`transaction:${transactionId}`, JSON.stringify({\n key,\n newValue,\n status: 'committed'\n }))\n ]);\n \n return { success: true };\n } catch (error) {\n \/\/ Mark transaction as failed\n await cache.set(`transaction:${transactionId}`, JSON.stringify({\n key,\n newValue,\n status: 'failed',\n error: error.message\n }));\n \n throw error;\n }\n}\n<\/code><\/pre>\nThis approach is more complex but provides stronger consistency guarantees for critical operations.<\/p>\n
Cache Versioning<\/h3>\n
Instead of invalidating cache entries, update a version identifier:<\/p>\n
\/\/ Initialize or increment version\nasync function incrementResourceVersion(resourceType) {\n const versionKey = `version:${resourceType}`;\n const currentVersion = await cache.get(versionKey) || 0;\n const newVersion = parseInt(currentVersion) + 1;\n \n await cache.set(versionKey, newVersion);\n return newVersion;\n}\n\n\/\/ When fetching data, include the version in the cache key\nasync function getResource(resourceType, resourceId) {\n const versionKey = `version:${resourceType}`;\n const version = await cache.get(versionKey) || 1;\n \n const cacheKey = `${resourceType}:${resourceId}:v${version}`;\n \n const cached = await cache.get(cacheKey);\n if (cached) return JSON.parse(cached);\n \n \/\/ Cache miss - fetch from database\n const resource = await database.getResource(resourceType, resourceId);\n \n \/\/ Cache with version\n await cache.set(cacheKey, JSON.stringify(resource));\n \n return resource;\n}\n\n\/\/ When updating resources, increment the version\nasync function updateResource(resourceType, resourceId, data) {\n \/\/ Update in database\n await database.updateResource(resourceType, resourceId, data);\n \n \/\/ Increment version instead of invalidating specific keys\n await incrementResourceVersion(resourceType);\n \n return { success: true };\n}\n<\/code><\/pre>\nThis pattern works well for resources that are frequently updated and where fine-grained invalidation is difficult.<\/p>\n
Distributed Caching Challenges<\/h2>\n
Distributed caching introduces additional complexity:<\/p>\n
Cache Coherence<\/h3>\n
In a distributed system, ensuring all cache instances have consistent data is challenging. Solutions include:<\/p>\n
Centralized Cache<\/strong><\/p>\nUsing a service like Redis or Memcached as a shared cache:<\/p>\n
\/\/ All application instances use the same Redis cache\nconst redis = require('redis');\nconst client = redis.createClient({\n host: 'central-redis-server',\n port: 6379\n});\n\nasync function getData(key) {\n return new Promise((resolve, reject) => {\n client.get(key, (err, result) => {\n if (err) return reject(err);\n resolve(result ? JSON.parse(result) : null);\n });\n });\n}\n<\/code><\/pre>\nPublish\/Subscribe for Invalidation<\/strong><\/p>\nUsing a pub\/sub mechanism to coordinate cache invalidation:<\/p>\n
\/\/ Setup Redis pub\/sub\nconst subscriber = redis.createClient(redisConfig);\nconst publisher = redis.createClient(redisConfig);\n\n\/\/ Subscribe to cache invalidation events\nsubscriber.subscribe('cache-invalidation');\nsubscriber.on('message', (channel, message) => {\n if (channel === 'cache-invalidation') {\n const { key } = JSON.parse(message);\n localCache.delete(key); \/\/ Invalidate local cache\n console.log(`Invalidated cache key: ${key}`);\n }\n});\n\n\/\/ When data changes, publish invalidation event\nasync function invalidateCache(key) {\n await publisher.publish('cache-invalidation', JSON.stringify({ key }));\n}\n<\/code><\/pre>\nPartial Failures<\/h3>\n
In distributed systems, some cache nodes might be unreachable. Strategies include:<\/p>\n
\n- Circuit Breakers<\/strong>: Prevent cascading failures when cache services are down<\/li>\n
- Fallbacks<\/strong>: Gracefully degrade to database queries when cache is unavailable<\/li>\n
- Bulkheads<\/strong>: Isolate cache failures from affecting the entire system<\/li>\n<\/ul>\n
async function getCachedData(key) {\n try {\n \/\/ Try to get from cache with timeout\n const cachedData = await Promise.race([\n cache.get(key),\n new Promise((_, reject) => \n setTimeout(() => reject(new Error('Cache timeout')), 100)\n )\n ]);\n \n if (cachedData) return JSON.parse(cachedData);\n } catch (error) {\n \/\/ Log cache failure but continue\n logger.warn(`Cache failure: ${error.message}`);\n metrics.increment('cache.failures');\n }\n \n \/\/ Fallback to database\n return await database.getData(key);\n}\n<\/code><\/pre>\nTesting Strategies for Cached Systems<\/h2>\n
Testing caching logic is crucial for preventing consistency issues:<\/p>\n
Unit Testing Cache Logic<\/h3>\n\/\/ Jest example testing cache-aside pattern\ntest('should return cached data when available', async () => {\n \/\/ Mock cache\n const mockCache = {\n get: jest.fn().mockResolvedValue(JSON.stringify({ name: 'Cached User' })),\n set: jest.fn()\n };\n \n \/\/ Mock database\n const mockDb = {\n getUserProfile: jest.fn()\n };\n \n const userService = new UserService(mockCache, mockDb);\n const result = await userService.getUserProfile('user123');\n \n expect(result).toEqual({ name: 'Cached User' });\n expect(mockCache.get).toHaveBeenCalledWith('user:user123:profile');\n expect(mockDb.getUserProfile).not.toHaveBeenCalled();\n});\n\ntest('should fetch from database on cache miss', async () => {\n \/\/ Mock cache miss\n const mockCache = {\n get: jest.fn().mockResolvedValue(null),\n set: jest.fn()\n };\n \n \/\/ Mock database\n const mockDb = {\n getUserProfile: jest.fn().mockResolvedValue({ name: 'Database User' })\n };\n \n const userService = new UserService(mockCache, mockDb);\n const result = await userService.getUserProfile('user123');\n \n expect(result).toEqual({ name: 'Database User' });\n expect(mockCache.get).toHaveBeenCalledWith('user:user123:profile');\n expect(mockDb.getUserProfile).toHaveBeenCalledWith('user123');\n expect(mockCache.set).toHaveBeenCalled();\n});\n<\/code><\/pre>\nIntegration Testing<\/h3>\n
Test the full caching flow with a real or containerized cache:<\/p>\n
\/\/ Integration test with real Redis\ndescribe('User profile caching integration', () => {\n let redisClient;\n let userService;\n \n beforeAll(async () => {\n redisClient = new Redis({\n host: 'localhost',\n port: 6379\n });\n \n userService = new UserService(\n new RedisCache(redisClient),\n new UserDatabase()\n );\n });\n \n afterAll(async () => {\n await redisClient.quit();\n });\n \n beforeEach(async () => {\n await redisClient.flushall();\n });\n \n test('should cache user profile after first request', async () => {\n \/\/ First request should hit database\n const profile1 = await userService.getUserProfile('test-user');\n \n \/\/ Verify profile is now in cache\n const cachedData = await redisClient.get('user:test-user:profile');\n expect(cachedData).not.toBeNull();\n expect(JSON.parse(cachedData)).toEqual(profile1);\n \n \/\/ Second request should use cache\n const startTime = Date.now();\n const profile2 = await userService.getUserProfile('test-user');\n const duration = Date.now() - startTime;\n \n expect(profile2).toEqual(profile1);\n expect(duration).toBeLessThan(10); \/\/ Should be very fast\n });\n});\n<\/code><\/pre>\nChaos Testing<\/h3>\n
Simulate cache failures and network partitions to ensure system resilience:<\/p>\n
test('should handle cache failure gracefully', async () => {\n \/\/ Mock a failing cache\n const mockCache = {\n get: jest.fn().mockRejectedValue(new Error('Connection refused')),\n set: jest.fn().mockRejectedValue(new Error('Connection refused'))\n };\n \n const mockDb = {\n getUserProfile: jest.fn().mockResolvedValue({ name: 'Fallback User' })\n };\n \n const userService = new UserService(mockCache, mockDb);\n \n \/\/ System should fall back to database\n const result = await userService.getUserProfile('user123');\n \n expect(result).toEqual({ name: 'Fallback User' });\n expect(mockDb.getUserProfile).toHaveBeenCalledWith('user123');\n});\n<\/code><\/pre>\nMonitoring and Observability for Cache Health<\/h2>\n
Proper monitoring is essential for detecting and diagnosing cache-related issues:<\/p>\n
Key Metrics to Monitor<\/h3>\n\n- Cache Hit Rate<\/strong>: Percentage of requests served from cache<\/li>\n
- Cache Latency<\/strong>: Time taken for cache operations<\/li>\n
- Cache Size<\/strong>: Memory usage of the cache<\/li>\n
- Cache Evictions<\/strong>: Number of items removed due to memory pressure<\/li>\n
- Cache Errors<\/strong>: Failed cache operations<\/li>\n<\/ul>\n
\/\/ Example middleware for HTTP cache monitoring\nfunction cacheMetricsMiddleware(req, res, next) {\n const startTime = Date.now();\n \n \/\/ Store original cache methods to wrap them\n const originalGet = cache.get;\n \n \/\/ Wrap cache.get to collect metrics\n cache.get = async function(key) {\n try {\n const result = await originalGet.call(cache, key);\n const duration = Date.now() - startTime;\n \n if (result) {\n metrics.increment('cache.hits');\n metrics.timing('cache.hit.duration', duration);\n } else {\n metrics.increment('cache.misses');\n }\n \n return result;\n } catch (error) {\n metrics.increment('cache.errors');\n throw error;\n }\n };\n \n next();\n \n \/\/ Restore original method after request\n res.on('finish', () => {\n cache.get = originalGet;\n });\n}\n<\/code><\/pre>\nLogging for Cache Operations<\/h3>\n
Implement structured logging for cache operations:<\/p>\n
class CacheLogger {\n constructor(cache, logger) {\n this.cache = cache;\n this.logger = logger;\n }\n \n async get(key) {\n const start = Date.now();\n try {\n const result = await this.cache.get(key);\n const duration = Date.now() - start;\n \n this.logger.debug({\n operation: 'cache.get',\n key,\n hit: !!result,\n duration\n });\n \n return result;\n } catch (error) {\n this.logger.error({\n operation: 'cache.get',\n key,\n error: error.message,\n stack: error.stack\n });\n throw error;\n }\n }\n \n \/\/ Similar wrappers for set, delete, etc.\n}\n<\/code><\/pre>\nDistributed Tracing<\/h3>\n
Implement distributed tracing to understand how caching affects request flows:<\/p>\n
async function getUserData(userId, tracingContext) {
\n const span = tracer.startSpan('getUserData', {
\n childOf: tracingContext
\n });<\/p>\n try {
\n span.setTag('userId', userId);<\/p>\n
const cacheSpan = tracer.startSpan('cache.get', { childOf: span });
\n const cachedData = await cache.get(`user:${userId}`);
\n cacheSpan.setTag('cache.hit', !!cachedData);
\n cacheSpan.finish();<\/p>\n
if (cachedData) {
\n span.setTag('data_source', 'cache');
\n span.finish();
\n return JSON.parse(cachedData);
\n }<\/p>\n
const dbSpan = tracer.startSpan('database.query', { childOf: span });
\n const userData = await database.getUserById(userId);
\n dbSpan.finish();<\/p>\n","protected":false},"excerpt":{"rendered":"
In the world of software development, caching is often introduced as a performance optimization technique. And indeed, when implemented correctly,…<\/p>\n","protected":false},"author":1,"featured_media":7449,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-7450","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-problem-solving"],"_links":{"self":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/7450"}],"collection":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/comments?post=7450"}],"version-history":[{"count":0,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/posts\/7450\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media\/7449"}],"wp:attachment":[{"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/media?parent=7450"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/categories?post=7450"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/algocademy.com\/blog\/wp-json\/wp\/v2\/tags?post=7450"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}