I've always been curious on how services such as google/youtube have multiple datacenters across the globe to serve requests faster to users while keeping their whole dataset structure intact. There has to be a "master database", right? But then again if lets say the database is in the US and a server in Ireland is handling the request, the database speeds would be slow and it would be the equivelant of the user querying a US server from Ireland. Do they have a "dns lookup" type of strategy where there's multiple instances of the database, queries closest databases to see if it has the data and if it does, cache it in the closest one. I might use this in the future once my application gets big enough, but i'm simply not sure how they manage to keep their database intact with multiple datacenters in different countries, while keeping the latency low.
Video distribution sites like YouTube are read heavy and bandwidth heavy data users, but in terms of complexity, they're relatively simple to scale. They're essentially a CDN type scaling where you can easily replicate the data in widely distributed caches close to the user. Only the first few downloads of new videos requires hitting the main database, but then after it becomes apparent that a content is popular in a certain region, it can be cached on the edge server close to the user.
Also, the transactional requirement of YouTube is fairly simple, for most of its system, it doesn't matter to actually have consistency, so they can take advantage of eventual consistency systems. Updates to videos are also relatively infrequent and if it takes a few minutes or even hours for updates to the video or comments to appear to the rest of the world, that's relatively inconsequential.
a "master database"
A master database probably exists, but in all likelihood, there are probably multiple master databases. Traditional databases enforces strong consistency guarantees called ACID, but for databases that needs to scale horizontally and doesn't actually need strong consistency, you can use a looser constraint called BASE.
Updates on a distributed, eventually consistent database typically are shared between master databases as a set of timestamped or a partially ordered description of the change, in a structure known as a "log". All of the masters exchanges these descriptions with each other through some form of gossip mechanism. The key to distributed database is that each master then can end up with the latest state of the world by replaying those logs on their current view of the state of the world. The log mechanism are designed to have a way to detect and resolve conflicting and duplicate changes, so that even if different masters plays the logs in different orders, they'll eventually reach the same final state. A simple conflict resolution might be to discard the effect of older log entries that have been completely overwritten by a newer one, or the might be algorithms to merge these changes.
The main characteristic of an eventually consistent system is that there's not necessarily a single master data, but if we stopped all updates to the system and just let the gossips to continue, all of the masters will eventually reach the same final state.
BASE is not the only way to achieve distributed systems, but it's one of the most common one for when strict consistency isn't required.
This is a very broad question with a very broad answer. There are a lot of things involved. The examples you mentioned are distributed systems. The characteristics you mention are obtained by scaling the systems horizontally instead of vertical as it tended to be some time ago. See for example this post on database scaling. And there is also not a specific architecture that one can use to build a distributed application. It depends on how much data you have, on what your use cases are, on what properties you are looking for, etc. It's no longer a matter of having one central relational database, with maybe some data replication in a few geographical areas, and becomes more about choosing a proper architecture and the proper technologies. That's why there are so many NoSQL solutions for example, because they are tailored to specific use cases.
I could go on, but like I said, this is a broad topic. In ending I just want to mention the CAP theorem and eventual consistency, whose descriptions should give you more insight into the ways, or better said, the compromises you need to be aware of, to make distributed systems work to meet your specific needs.