Imagine building a social media application.
Users can create accounts, follow people, publish posts, and view their home timelines.
Everything works as expected.
But there's a problem.
As more people start using the application, loading the home timeline becomes painfully slow.
The features work, but the experience isn't good.
This is where nonfunctional requirements become important.
I'm reading Designing Data-Intensive Applications by Martin Kleppmann, and one thing that stood out to me is that building an application isn't just about deciding what it should do. We also need to think about how well it should do it.
Two performance concepts from this chapter caught my attention:
1. Response time
How long does a user wait between making a request and receiving a response?
For example, how long does it take to load their home timeline?
2. Throughput
How many requests can the system process within a given period?
For example, how many timeline requests can your application handle per second?
These two are related, but they aren't the same.
A system might handle thousands of requests per second and still have users waiting several seconds for their requests to complete.
The chapter also explains something interesting about overloaded systems.
When a server gets too busy, requests start waiting in queues. Some clients eventually time out and retry their requests.
Those retries create even more traffic, making an already overloaded system struggle even more.
It's a cycle that can turn a performance problem into a serious outage.
One thing I'm beginning to understand is that performance isn't just about making code execute faster.
It's also about understanding how a system behaves under load and what users actually experience.
Developers, when you're building an application, do you think about performance requirements from the beginning, or do you usually start worrying about them when users begin complaining?
Top comments (0)