[ipozgaj]

Not sure why are you getting downvoted, I came here to make the same comment.

QPM is a useless metric. When talking about distributed systems from engineering point of view, you always want to use QPS. QPM is simply not fined-grained enough to show whether the traffic is bursty or not. For example in this particular case, when you say 1M QPM that can mean anything - they might be idle for 50s and then get 100k QPS for the next ten seconds, or they might be getting 15k QPS all the time (like it's visible on the graph). Distributed systems are designed for the peak workload, not for the average one. Using misleading numbers like QPM leads to bad design and sizing decisions.

The only case where you would use QPM, QPD and similar metrics is when you want to artificially show your numbers bigger than they are (10M transactions a day sounds better than 115 transactions a second). But those should be used by sales, not by engineers.

[sethammons]

I read it originally as 1M QPS, and thought that was a nice number. It was upon further inspection that I saw it was 1M QPM, and I was no longer intrigued.

[Kiro]

What kind of stuff do you build where you have 1M QPS?

[sethammons]

I'm not sure if my org qualifies. Depends on how you count it I guess. We have 80k+ RPS at times at SendGrid, and each request can generate 4 to 8 external events and at least a dozen internal API calls. If you count total internal QPS, that would be something in the order of 80k * 4 * 12 ~= 3.8M QPS. I'd have to check with an operations person to see if that checks out. I don't know if it is fair to count this though. So, let's go back to the 80k RPS. If someone was doing 10X that, I'd be intrigued to learn more about their set up for sure. I imagine the Googles, Facebooks, and Amazons of our industry do this level of traffic.