Hacker News Reader

Comment by fourier76 | Hacker News Reader

What if you get one push event on the first second, and then 999,999 on the last second? Still one million per hour. Don’t assume the events are evenly distributed. I see this a lot on HN. Yes, 1,000,000 divided by 3600 is indeed about 278, but why would we assume it was 278 notifications exactly every second?

View on HN

Then they should have said they can handle a million push notifications a second.

That doesn’t make sense?

I think very few people, even on Hacker News, are so pedantic to argue strongly that someone is lying when they call 999,999 notifications in one second "a million".

Queue it. It's not particularly urgent that push notifications go out instantaneously. A 99th percentile latency of 5 minutes is fine.

Not if it’s your ride waiting for you in short-term parking space, or a food delivery person at your doorstep.

> or a food delivery person at your doorstep.

That's what doorbells are for.

Haha I look forward to an IoT doorbell company blogging about how they send 2 million door bell rings per second

Nothing says you must handle them all at once though. You could queue and handle as your system allows... still reaching a 1 million per hour throughput.

Sure, but just because the average is 278 per second doesn’t mean the events happen at that rate. Bursts are way harder to process, which is much more typical. But someone writes an article like “How We Handle X things every Y”, and inevitably someone does basic division and surmises that it shouldn’t be so hard.

> Bursts are way harder to process

They aren't though. There are very few use cases that aren't bursty, and a plethora of reliable queueing systems exist.

Queues eliminate bursts, bursts are not harder to process unless the response must by synchronous.

Reply on news.ycombinator.com