180M/s is the peak throughput I've observed from the entire fleet, and is an accurate figure.
It's worth noting that:
(1) When it comes to caching workloads, there is often a wide spread of request amplification factor from a single inbound user request to the site. For example, a search query on Pinterest might internally fan out to an order of magnitude more requests to memcached across several different services along the request path used for servicing that query.
(2) There are many systems outside of the online critical path that use caching, which add load on the system independent of the rate at which users are posting or viewing content on the Pinterest site.
As another reference point, Facebook, who developed mcrouter, shared that their memcached deployment serves on the order of billions of requests per second [0]. And this figure is from 2014; I imagine it's grown a lot since then.
[0] https://www.usenix.org/system/files/conference/nsdi13/nsdi13...
However, your main point is valid (180 million/s seems way too high). I've started a thread internally to double check these numbers. Please wait for an update.
All right. But, here's my source - https://www.google.com/search?q=how+many+requests+does+googl... . Maybe, it's flawed
As an anecdote, I've worked at a scale up that handled ~20M HTTP(S) req/min on their service mesh.
The rule of thumb was that our Redis cache layer would have 10x the number of HTTP request, so 200M req/min.
Note that I'm using minutes, not seconds on the units. But it wouldn't surprise me that Pinterest handles 60x the load that we had back then.
Honestly not that high of a number from memcached [1] prospective. It could easily handle 10x that even with SSD extstore.
For comparison, Google serves about 63k queries per second. I hope there's not a typo in the above line in Pinterest's blog