DEV Community

Cover image for Scalability in Data-Intensive applications - Fan-Out, Throughput, Twitter problem, Percentile
Oleksandr Kashytskyi
Oleksandr Kashytskyi

Posted on

1 1 1

Scalability in Data-Intensive applications - Fan-Out, Throughput, Twitter problem, Percentile

Introduction

As applications grow, they need to handle more users, more data, and more requests efficiently. Scalability is a term used to describe a system's ability to cope with an increasing load. But how do we ensure that a system scales well? Let's explore some key concepts.

Identifying Bottlenecks

To scale a system effectively, it's essential to analyze its load parameters. Different systems have different constraints, and finding bottlenecks helps in optimizing performance. Here are several key factors to consider:

  • Fan-out: It's a term which describes the number of requests a service or endpoint makes to other services in order to serve a single incoming call. A high fan-out can lead to increased latency and system overload.

  • Throughput: In batch processing systems like Hadoop, the focus is on records processed per second rather than individual response times.

  • Response Time Distribution: Measuring response time is not just about average values but understanding the distribution of values.

The Twitter Problem

A classic example of scalability challenges is Twitter's timeline system. There are two endpoints, one to create a new post and another to fetch newest 20 posts.

A naive approach would be to query the database every time a user requests their home timeline. This results in expensive read operations and high latency.

Instead, Twitter solves this problem by maintaining a cache for each user's homepage. As cache memory is very expensive, there can't be stored all data needed for response, but it's possible to easily store IDs of last 20 posts in the timeline. This approach increases write complexity (It will be necessary to maintain both posts in a database and cache storage), but significantly improves GET request performance.

Measuring Response Time Effectively

Response time can vary significantly depending on system load. One of the best ways to analyze it is through percentiles, rather than averages.

99.9th percentile is often used to track performance (Some companies, like AWS AWS for example use 99.99th percentile). The reasoning behind this is that the top 0.1% of users are usually the most valuable customers, often transferring the most data or making the most critical requests.

Example: Sentry Monitoring: In observability tools like Sentry, response time percentiles help identify slowest transactions affecting real users, allowing engineers to optimize performance accordingly.

Conclusion

Scaling a system is not just about handling more traffic but ensuring efficiency, and optimal resource allocation.

Scalability is essential for handling growing demands in data-intensive applications. Identifying bottlenecks like fan-out, throughput, and response time distribution helps optimize performance. Finally, using percentiles instead of averages ensures a more accurate measure of system performance, helping engineers focus on critical optimizations.

Sentry image

Hands-on debugging session: instrument, monitor, and fix

Join Lazar for a hands-on session where you’ll build it, break it, debug it, and fix it. You’ll set up Sentry, track errors, use Session Replay and Tracing, and leverage some good ol’ AI to find and fix issues fast.

RSVP here →

Top comments (0)

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay