disclaimer: I'm not as knowledgeable on this subject as I would like to be, feel free to edit my mistakes; I've make some voluntary short-cuts to avoid rewriting wikipedia from scratch
Ok, let's scale down a bit: you're a successful app maker and you'll have to face some thousand users each day.
Here comes your first step in the big boy world, and the most important question:
what are you doing with your data?
From this question, your whole architecture will be chosen, and it will probably decide how smoothly things will go for you (remember the launch of pokemonGo? it was a big fail on this point).
- We only have a few writes (understand input data to store) but a sh*t load of reads.
Then you're after a single/small cluster of master DB (big R-DBMS, or 'any' distributed NoSql) and many replicas as slave (read-only) or world wide caching Content Delivery Network- CDN. This is a good fit for a website like News (the comment part is on another service, see after).
- we have read/write with a more classic ratio
You rule out the first option. Caching will help but not be enough and R-DBMS starts to be really expensive as you need a big cluster with distributed write (not a single master). You are most likely after some NoSQL solutions. You should still be able to use most of the classic ones, as this is why they were created. You'll have a pool of full master replicas or a beefy master and a pool of slave full replicas.
- you're funny with your "more read than write" thing, I'm about to put Twitter out of business, and have nearly more write that read...
Ok, here comes the real problem, the one that makes R-DBMS out of the question and gives nightmares to a bunch of engineers ... "how do we handle a write every micro second, with reads than can be 0 to Katy Perry's 100M followers?"
The answer is "not as easy as we would like." More seriously, the trick is "distributed data." You find a way to differentiate your data and store only a tiny part of it in each instance of storage (note that I'm not even really using "DB" here, it's the dark side of NoSql, the one that can live nearly on its own, and just face the world as what looks like a "file-system". So now you have a rule to store your data on distinct small instances. Good. The fun part is "how do we get them back?" And this is the big deal. Write is "easy" but read means you'll have to make some server a "front index of where things are," a routing gateway to the right storage space, but knowing where is the data is not the only thing to worry about.
Katy Perry is back, hide your DB, hide your server... You now can save and retrieve your data across a full datacenter. The point is, for now every single row is stored for a "normal use" with 2 redundant nodes, and it'll not be enough if this row goes viral. Before ending up with a toaster instead of your server, you'll have to use dynamic caching and/or node replication. "What'das" you ask? Well, as with the Ant algorithms, you'll have to put some weight on your data:
- who's posting?
- Katy Perry
Ok we'll maybe store them in more than 3 nodes for at least the next few weeks...
what the hell, this D. Trump Tweet from 2013 went viral today
Even if it seems the author and the date don't justify more node allocation than the default (did I just go full political ? my bad...), the popularity will trigger caching mechanism and temporary spread on to other nodes to match the demand.
For this solution, I explained step by step how it works, but the DBMS with a good configuration will do it for you.
As you can see, even when we just take a quick look at how to handle "the big", there is a lot to say. Keep in mind that most (all?) of these solutions where developed from the problem they solve: every big company makes their own DBMS from their use case. The NoSQL products are just the public release of what these companies have worked on to solve the need for custom solutions.