16k per second. 83k per second during peak (assuming 80/20 default traffic rule).
- 100 /s = typical limit of a standard web application (python/ruby), per core
- 1.000 /s = typical limit of an application running on a full system
- 10.000 /s = typical limit for fast systems (load balancers, DB, haproxy, redis, tomcat...).
- Over 10.000/s You gotta scale horizontally because a single box [shouldn't] can't take it.
The difficulty depends on the architecture and what the application has to do (dunno, didn't go through the article). You make something that can scale by just adding more boxes, then it's trivial, just add more boxes. Well, it's gonna costs money and that's about it.
So no. Not a big deal at all... if you've done that before and you've got the experience :D
While 1k/sec seems to be an average throughput for most web apps due to all the logic, 10k/sec is nowhere near the limit for fast systems, many can do well into 6 figures per second with some now doing millions/sec.
Your description for fast systems refers to high-performance software like load balancers and databases. In this case, 10k is nowhere near the limit on modern machines, they all do 6 figures per second.
With good hardware and good tuning, possibly. Again I'm not saying it's a hard limit, I'm saying it's a reasonable expectation for real world production usage ;)
At 100k requests/s on a load balancer. The HTTP headers alone (450 bytes) with zero content are more than 1300 MBps of traffic. And well, the CPU will bottleneck long before that amount of requests to parse.
Everything is relative. In this case, it's not so much the actual load itself but rather the throttling ability to match the upstream provider's throughput and limitations.
