Introduction: The Counting Problem

• Social media platforms (Twitter, YouTube) show fluctuating numbers for likes, views, subscribers
• Numbers go up/down randomly instead of steadily rising
• Screen recordings show real-time number fluctuations on tweets
• Computers should be good at counting but fail at scale

Single-Threaded vs Multi-Threaded Systems

• Previous coding examples were single-threaded (one instruction at a time)
• Modern systems require multi-threading for scale
• Most websites are fancy front-ends to databases
  • YouTube: database of videos and comments
  • Phone billing sites: database of customers and bank accounts
• Single computer/database has limited request capacity per second

Race Conditions Explained

• YouTube view counting example: seemingly simple "add 1" operation
• Actually three separate jobs:
  • Read current view count
  • Add one to it
  • Write new count back to database
• Multiple simultaneous requests create race conditions
  • Thread 1 reads count while Thread 2 calculates
  • Both threads write same number back
  • Result: missed view counts
• Popular videos experience constant collisions
• Worst case: 10-100 requests simultaneously, some get delayed
  • Delayed request adds 1 to original outdated number
  • Overwrites newer accurate count
  • Loses multiple view counts

Traditional Solutions and Limitations

• Early databases: collisions could corrupt entire system
• Modern databases: keep working but lose accuracy
• YouTube needs accuracy for ad revenue calculations
• Queue-based solution: process requests one at a time
  • Works for simple systems, doesn't scale
  • Million-person queue for YouTube videos = poor user experience
• Still used for critical accuracy needs (concert ticket sales)
  • 100% consistency required (can't sell same seat twice)
  • Ticket sites use queues, limit concurrent users

Eventual Consistency Solution

• Used by Big Data sites (YouTube, Twitter)
• Multiple servers worldwide maintain local counts
• Each server bundles viewcounts/statistics locally
• Updates central system when time permits
• Update frequency: seconds to minutes (not hours)
• Bundled updates easier on central system than millions of simultaneous requests
• Central database often multiple computers keeping each other updated

When Immediate Consistency is Required

• YouTube privacy settings: must update immediately everywhere
• Rare operations can stop everything temporarily
• Views/comments can wait briefly
• Servers log changes locally
• Periodic sync: every few seconds/minutes/hours depending on location
• Systems process logs and update central system when available

Caching Systems

• Explains up-and-down number fluctuations in tweets
• Reading from database also bundled, not just writing
• Thousands requesting same content shouldn't hit central system repeatedly
• Twitter example: 10,000 requests/second for one tweet (reasonable volume)
• Caches sit between users and central system
  • Thousands to tens of thousands of caches
  • Each cache queries central system once
  • Stores details in memory for seconds
  • Serves subsequent requests from memory
• Benefits:
  • Only tiny fraction of traffic hits central database
  • Orders of magnitude faster response
  • Can spin up more cache servers during traffic spikes

Cache Synchronization Issues

• Each cache pulls information at different times
• All caches out of sync with each other
• User requests routed to any available cache
• Different cache each time = different answers
• Explains number fluctuations users observe

Final Resolution

• Eventual consistency ensures no data loss over time
• Numbers settle once activity (retweets, views) stops
• Dust settles, everything gets properly counted
• Accurate counting at scale is genuinely difficult