[jerf]

"Scale" isn't a binary, it's a continuum. "Scales to 60K/s" can be 5 orders of magnitude more than one system needs and 5 orders of magnitude too small for another. Personally I'd knock the general "premature optimization" off the list of "most common developer errors" and put in its place "using techs with the wrong scaling factors". If you use something too small and you exceed its needs, the failure is obvious, but the other way around is a problem too. Bringing in the overhead and management issues of the super scalable techs, as well as their limitations they impose so that they can scale, to a system that would actually be better off with a richer model whose richness prevents it from scaling but would save a lot of effort is also a bad choice.

The ceiling of LISTEN/NOTIFY is small enough that you need to pay attention, and I personally like to have at least an order of magnitude of slack left over even after my most pessimistic load numbers are accounted for, but it's still plenty for a lot of projects, and the integration with the rest of the DB, its availability, its not being another service you have to devops, it's definitely not something that should be simply dismissed out of hand as an option. Even the original 2K/s number they cite is a lot of messages for some systems that are more properly measured in seconds per message.

[zbentley]

> 5 orders of magnitude too small for another.

Nitpick on an otherwise good post, but I don’t think there are very many 6billion RPS systems out there, and those that do exist are almost certainly using bespoke, purpose-built tools

[odo1242]

The highest I could think of is WhatsApp, which gets ~1.6 million RPS on average, and they use MQTT

[illliillll]

I used to scrape Meta sites at over 200k steady rps for a couple of years, all by myself.

They did send lawyers to my door in the end though.

Someone had forgot IPv6 rate limit bucketing :)

[dr_dshiv]

Tell more sounds like a good story

[stingraycharles]

I work in manufacturing, you would be surprised at the volumes of sensor data being processed there for predictive maintenance.

MQTT is everywhere, indeed, because of how simple the protocol is (it’s very ubiquitous in IoT / embedded systems).

[znpy]

DynamoDB scales much more than that. In one of their dynamodb papers they claimed that the amazon us retail website alone made like 89 millions rps during prime day, a few years ago.

[dynotable]

89M rps was the peak across all Amazon systems during 2021 Prime Day. Alexa, Amazon.com and the fulfilment centres together, not one site. But its still very impressieve. But the more importarnt number is the per partition limit, 3000 RCU and 1000 WCU. Horizontal scale is the easy part, a table only gets near it if the partition key actually spreads.

[junon]

It's also one of the most aggravating database systems I've worked with.

[znpy]

It still scales though

[nly]

WhatsApp is primarily 1 to 1 messaging. Why would this be hard to scale? Scaling horizontally, sharding, and message routing is all it takes, surely?

[coreylane]

AWS IAM handles over 1.2 billion requests per second, based on a 2024 post, im sure its higher now https://aws.amazon.com/blogs/security/an-unexpected-discover...

[monster_truck]

Maybe there would be more if it were more straightforward to do so?

[ndriscoll]

For reference, I've seen Visa marketing materials that suggest their network can do ~70k TPS. There are not very many systems one could conceive of that could do useful work 1/s for ~every human on the planet.

[chmod775]

> There are not very many systems one could conceive of that could do useful work 1/s for ~every human on the planet.

Roughly a hundred servers on 100 GbE ports each could handle one small UDP packet per human every second, and would have a plenty of cycles and RAM per human left to actually do some work.

That fits in a shipping container.

Illustrative of course: the point is that "for every human" is not far out there given how crazy powerful hardware has become.

[AdieuToLogic]

>> For reference, I've seen Visa marketing materials that suggest their network can do ~70k TPS.

> Roughly a hundred servers on 100 GbE ports each could handle one small UDP packet per human every second ...

While there is no correlation between the Visa claim of 70k tps to people on the planet, there is also no correlation to the number of servers needed to process UDP packets.

The "Visa network" is more of a trusted collaboration between a small number of banks operating multi-step transactions than it is an OSI Layer 1 - 5 concern.

[chmod775]

> Illustrative of course: the point is that "for every human" is not far out there given how crazy powerful hardware has become.

[ksec]

Considering Visa's user Time zone and population density. I wouldn't be surprised if WeChat in China or UPI in India have higher TPS numbers.

But then again it would still be no where near a million TPS.

[iamflimflam1]

There is a tendency in tech to forget that there were highly scalable systems, processing huge numbers of transactions, before the internet and “hyper scalars” were a thing.

[literalAardvark]

It's also worth noting that all of those systems could be served by your phone.

[stavros]

Hm, what am I not getting? One transaction per second for every human on the planet would be 8 billion TPS, not 70k, no?

[ndriscoll]

Yes, the point is it's difficult to even conceive of something that needs anywhere near the billions of TPS, because generally speaking, humans are not doing something with a computer once per second on average. Far lower. I might use my credit card less than once per day on average.

[stavros]

Ah, yes, humans don't, but computers do. I'd imagine there are plenty of systems that ingest automated data (eg sensors) that need billions of TPS.

[paulddraper]

Doing 1 request for every person on this planet every second?

What are these, TCP packets?

[jerf]

Fair.

[10000truths]

Could be base 2. ~1.3M RPS is a lot higher than most will ever require, but still within the realm of possibility.

[mlyle]

I think if you expect to be under 60K/s and suddenly find yourself at 20K/s heading for 200K/s-- you have a better problem than if you built for 1M/s and actual load is 20K/s. The unexpected success of the former will pay for a lot of band-aids and scaling, while you're pretty stuck with the cost structure and upfront spent capital in the latter.

IMO one should design for actual anticipated scale with moderate margin, only exceeding this when it's relatively "free" to do so. (If you can buy bigger hardware for a few K, or if solutions are equivalent other than scalability, pick the bigger solution).

[nudpiedo]

In this case it does by hitting hardware maximum. It scales until the max it is possible, due the bottleneck being in the hardware, not in the database or i/o. Check the article again:

> At maximum throughput, Postgres CPU is fully utilized, showing the database is actually saturated instead of bottlenecked on contention.

[orf]

It doesn’t necessarily follow that because Postgres is “fully utilised” it is hitting “hardware maximum”, or even that it’s not bottlenecked on contention.

As an example, spinlocks can push CPU usage very high whilst being an obvious symptom of contention.