I believe it. I've never worked at Google, but I was the engineer for SMS/Voice registration at WhatsApp, ocassionally with one other engineer (I believe the team was 3 when I left, not sure if it grew); I think there were two engineers doing my job for Facebook; although they had a little bit more scope, since there were more kinds of SMS they sent. That doesn't have a huge request rate, but it is super important.

Something like DNS or BGP is going to have a tiny team and a huge impact. Load balancers probably has a bigger team, maybe 10-20 engineers, and almost everything goes through load balancers. And that's just the things that are easy to enumerate. I can think of lots of small teams when I was at Yahoo that worked on bits of software that are hard to explain, but were critical.

Exactly, there’s really like three dozen or so people globally who really should never be in the same room at the same time as the risk is too great they get hit by the same asteroid.

I’d put “person who makes sure WhatsApp verification codes work” on that list.

> I’d put “person who makes sure WhatsApp verification codes work” on that list.

Thanks! That part of my job really wasn't too hard though, once I got things in order; but it was the easiest part of my job to describe. Just a lot of debugging from sparse data, and trying to get things to work a smidge better, because smidges here and there add up. It really helped to have a great customer service team that bubbled up usable information from users.

Debugging things from sparse data gets you involved in a lot of different systems though... That and I told people I worked at an ISP in the before times, so guess who got to fight with sendmail, and guess who got to own our Domain accounts and DNS accounts and guess who got to get x.509 certificates, and who had to fight with Google Apps to make mandatory 2fa usable, etc. Basically everything without a person and server adjacent got me. :P

Anyway, I've moved on (replaced by a team of three on the SMS stuff amyway, much better bus factor) and am semi-retired and no longer in any critical path, which is a lot less stress.

World population is 8.2 billion. Assume that 1/3 are asleep at any given time, leaving 5.5 billion awake. It’s not a huge stretch to imagine 20% of them (1.1 billion) using core Google services during peak times.

I don't find it hard to believe. I am not at Google but I work on a product with 200 million MAU, in a core team that serves requests to every single one of those users and there are 6 of us.

Out of curiosity, what proof are you expecting to get? An internal Google usage report and a list of developer names that work on core infra?

Can’t, but not sure why that’s hard to believe?

Because billions of people or their devices aren't even online every hour.

Unless you're discussing background processes on google's side

Push notifications need to connect to that many devices every hour easily

You may not get a notification every hour, but the phone still have to connect to Google APIs to check to know that.

You can say same thing about say location services, every phone if powered and connected to the internet would ping more than one an hour, more than billion devices are definitely online at any give time, not just Android phones, also every android TV, tablet, watch, and the hundreds if not thousands of other devices running GMS on top of AOSP .

There are probably few other APIs in GMS that would ping at least once an hour each device that is powered on, perhaps things like NTP for timing alerts or Emergency Alerts etc.

You may consider them "Background Services" , most of them however have some foreground UI if they need to, and users will notice if they don't work

There are roughly 5 billion smartphone users now, those devices are almost always on and sending background data somewhere. By volume, more of that data guess to Google than anybody else, on the order of hundreds of network requests per device, per hour.