Why Computers Can't Count Sometimes

Tom Scott

12 Nov 201808:44

Summary

TLDRThe video explains why view and subscriber counts can be inconsistent on sites like YouTube and Twitter. It comes down to race conditions when requests collide, eventual consistency where updates are batched, and caching where different servers supply slightly outdated information. Calculating accurately at scale is difficult. So while the final counts will be correct, there can be lag and fluctuations before the dust settles.

Q & A

Why can view counts and subscriber counts sometimes fluctuate or be inaccurate on sites like YouTube?
-This can happen due to race conditions when requests collide, as well as caching, where different caches store slightly different view counts that get served to users randomly. Overall it takes time for the eventual consistency to resolve across the distributed system.
What is a race condition and how does it cause issues with accuracy?
-A race condition happens when multiple threads try to read, update and write data at the same time, and the final result depends on the order those operations occur in. This can result in lost updates.
How does queueing requests help accuracy?
-Putting all requests in a queue and processing them one by one ensures updates cannot collide. However, this does not scale well to sites with enormous traffic volumes.
What is eventual consistency?
-Eventual consistency is where distributed databases sync up less frequently to reduce load, allowing counts to be slightly wrong temporarily before resolving. This scales better but accuracy lags.
What is caching and how does it help sites handle traffic?
-Caching is keeping commonly requested data in fast memory to avoid hitting the main database every time. This improves performance dramatically but can cause inconsistent results.
Why can buying something like concert tickets require stronger consistency?
-For buying tickets, it would be very problematic if race conditions allowed the same seat to be sold twice. So stronger consistency guarantees are needed, even if it reduces scalability.
Why is scaling database systems to handle massive traffic difficult?
-Every request takes time to process. At large scale the volume can overwhelm a single database. Solutions like caching and eventual consistency help but reduce accuracy.
How could the issues explained impact something like tracking ad revenue?
-Inaccurate counts could lead to incorrect ad revenue tracking. However important metrics usually use stronger consistency. Caching and lagging mostly impacts secondary data like page views.
What are some ways sites balance consistency and scalability?
-They prioritize stronger guarantees for important things like financial data, while allowing lags and inaccuracies temporarily for secondary metrics. Different tradeoffs per metric.
Why is accurate counting harder than it may appear at first glance?
-Even simple incrementing relies on separate read, calculate and write steps. At scale these collide across threads and servers, with caching adding further complexity on large systems.

Keywords

💡race condition

A race condition occurs when two or more processes or threads access a shared resource in an unpredictable order. This can lead to inconsistent outputs or data corruption. The video explains how race conditions can happen when multiple requests try to update a database count at the same time, causing some updates to get lost.

💡eventual consistency

Eventual consistency is a consistency model used in distributed computing where replicas of a database are allowed to temporarily have different data. The data will eventually become consistent once it has been replicated across all database copies. The video explains how YouTube uses eventual consistency to update view counts without overloading its central databases.

💡caching

Caching refers to storing data in a temporary storage location that allows for fast retrieval. The video explains how Twitter and other sites use caching servers to quickly serve commonly requested data instead of hitting backend databases every time.

💡scaling

Scaling refers to the ability of a system to handle increasing loads. The video notes that scaling systems to deal with large traffic volumes introduces challenges like race conditions and consistency issues.

💡queue

A queue is a linear data structure where elements are inserted at one end (the back) and removed from the other end (the front). The video mentions how queues can be used to serialize database updates and prevent race conditions, but don't scale well.

💡thread

A thread is a sequence of instructions that can be executed concurrently with other threads. Multi-threaded systems introduce challenges like race conditions because thread execution order can vary.

💡latency

Latency refers to delays in processing data or transactions. The video explains why view counts can be inconsistent - updates are latent as data gets replicated across databases.

💡bottleneck

A bottleneck is a point in a system that limits overall throughput. The video implies that central databases can become bottlenecks if directly hit with large traffic volumes, motivating caching and queues.

💡vertical scaling

Vertical scaling involves increasing the processing power of individual servers. The video notes how additional cache servers can be spun up to handle increased loads.

💡consistency

Consistency refers to all replicas in a distributed system reflecting the same data. The video contrasts strong consistency models with eventual consistency.

Highlights

Counting things accurately is really difficult at scale due to race conditions, caching, and eventual consistency.

Race conditions happen when code tries to do multiple things at once and the order affects the result in an uncontrolled way.

Putting all requests in a queue and processing them one by one avoids race conditions but does not scale up.

Eventual consistency bundles updates over time rather than reporting every single change right away to relieve pressure on the system.

YouTube view counts may lag because updates are bundled and sent less frequently from local servers to the central database.

Buying tickets uses a queue system to avoid selling the same ticket to multiple people, ensuring 100% consistency.

Caching stores commonly requested information in fast memory to avoid hitting slower databases for every single request.

Different caches pull data at different times, so requests routed randomly between them show inconsistent results before eventual consistency.

Adding cache servers easily handles sudden traffic spikes without worrying the central database.

Old single-threaded computers execute instructions one by one without accepting new inputs until finished.

Modern systems break large tasks like databases into distributed pieces that eventually reconcile.

Core databases use multiple computers to update each other for redundancy and scale.

Accuracy is sacrificed for availability and partition tolerance in large eventually consistent systems.

Updates like video privacy settings require immediate total consistency so pause other operations.

Given enough time, eventually consistent systems converge on accurate counts despite short-term noise.