Skip to content →

Notes on Data-Intensive Applications

  • These days, the bottleneck of most Internet apps is around the handling of large amounts of data; not CPU.

  • Data-intensive applications run on a system that usually includes:
    • Database (somewhere to keep the data long-term)
    • Cache (users expect fast responses and page loads)
    • Search Index (users expect to be able to search for things and get results quickly)
    • Stream Processing (performing heavy operations asynchronously using message queues)
    • Batch Processing (periodically crunch large datasets to generate reports, do analyses, etc)

  • In order to survive and compete, businesses need to run on systems that are reliable, scalable, and maintainable.

  • Reliability – Does the system still work if something breaks?
    • Hardware, software, human faults
    • Human faults happen more than one might expect, so automation is a good thing.

  • Scalability – Do users get the same response time at peak-hours vs slow hours?
    • Numbers are important!
    • In order to discuss scalability, we first need ways of describing load and performance quantitatively
    • Describe the load. Examples: requests per second, read/write ratios, cache hits vs misses, number of users online at a certain time.
    • Latency is not the same as response time. Latency is the time a request is waiting to be handled. Response time is what the user sees. Total time from request to response; including network delays and backend processing time.
    • Response time will be different on each request, so don’t treat it as a number, but a distribution of numbers.
    • The mean (average) response time is not a good metric because it doesn’t tell you how many users waited that long. Instead, use the median response time, and describe using percentiles.
      • For example, if the 95th percentile response time is 1.5 seconds, that means 95 out of 100 requests take less than 1.5 seconds, and 5 out of 100 requests take 1.5 seconds or more. 

  • Maintainability – Can a new engineer on board and contribute to the code base without ripping all their hair out?
    • Operability – Routine tasks should be easy to do
    • Simplicity – Removing accidental complexity that resulted from underlying issues
    • Evolvability – Easily adapt to changing requirements

Published in Today I Learned