7. Decoding the Internet: From DNS to Advanced Service Discovery

How does the invisible architecture of the internet keep everything running smoothly? Prepare to have your mind blown as we unravel the mysteries of the Domain Name System (DNS) in this episode of Learn System Design. We'll guide you through the intricate process of how your browser finds the correct IP address for a domain name, likening DNS to an enormous, sophisticated key-value database. Discover the essential components that make DNS work seamlessly, from DNS servers and resource records to caching mechanisms. We break down the DNS hierarchy, explaining the pivotal roles of recursive resolvers, root name servers, and top-level domain servers.

But that's not all—we're also diving deep into the world of service discovery patterns. Which is better: client-side or server-side discovery? We'll weigh the pros and cons of each, spotlighting real-world examples like Netflix's Eureka and AWS Elastic Load Balancer. Learn why a service registry is crucial for maintaining an updated list of services and how heartbeat checks fit into this ecosystem. Finally, we explore three popular service discovery methods—DNS-based, Apache Zookeeper, and sidecar services—giving you an in-depth look at their benefits and limitations. This episode is your ultimate guide to building robust and efficient systems, so tune in and elevate your system design knowledge!

Learn more about the different types of DNS Records (Zone files)

Chapters

• 0:00 Understanding DNS Infrastructure and Domain Names
• 15:06 Comparing Service Discovery Patterns

Transcript

Speaker 1: 0:00

Hello everyone, welcome to episode number seven of the Learn System Design podcast. It's been a while. I just want to start off thanking everyone that reached out, that sent the emails, that sent the messages. I appreciate everyone for their patience. It's been a little bit and I understand. Unfortunately, I'm a one-man operation. I had a family emergency that basically has been taking up all of my time along with my actual 9-to-5 job, so I'm a little behind. I'm hoping to catch up and get back on a more strict schedule, but for now, these episodes will be coming as fast as I can make them, but they will be coming as fast as I can make them, but they will be coming.

Speaker 1: 0:45

With all of this out of the way, let's talk about today's topic domain name systems, or DNS for short. Dns in its simplest form is what makes our casual internet browsing possible, but, as we will learn today, it also serves a huge purpose for how we understand our services and how our services actually communicate with each other. Thank you, if you are listening to this podcast, there's a pretty good chance you have at least visited one website in your life. If you haven't, then perhaps you're some sort of time traveler and unfortunately, I don't think this podcast will help you much. Maybe you can help me sometime. Unfortunately, I don't think this podcast will help you much. Maybe you can help me sometime. However, for the rest of us, if you've visited a website, have you ever wondered how the computer knows where to find googlecom or TikTok or anything like that? Well, the answer is a bit more straightforward than you might think. Dns was invented the same year that my sister, crystal was born 1985. And while my sister grew and changed and became better, unfortunately DNS did not. It's actually remained the same over the last 40-ish years.

Speaker 1: 2:40

When you visit any kind of website, your browser usually makes a request to your ISP. Sometimes your DNS lives elsewhere, but for most of us it's our ISP and it just passes the name of the website you just entered. Then your ISP makes an actual request to a DNS infrastructure, dns infrastructure and the DNS infrastructure does a lot of fun stuff and sends back an IP address which then your browser uses to serve up all the information for a website. So let's take a second here, take a step back and touch on what an IP address is. Well, I can assume most of you know some of you actually may not An IP or internet protocol address can be thought of like a physical address to your house. It lets the internet know where to find your specific server, and by your I mean googlecom or anyone who's hosting a website. So when your browser actually sends that initial googlecom message, the DNS infrastructure looks up in its database what IP is mapped to googlecom and sends back the IP of that specific server.

Speaker 1: 3:58

So it's a little more complicated than that, but at a high level that's how it works. You can imagine it as just a key value database. It's a little more complicated than that, but at a high level that's how it works. You can imagine it as just a key value database. If DNS wasn't so intricate and the internet wasn't so big, we could actually get away with this. We could actually just say for every domain name, return a specific IP and just have a key value pair, ip and just have a key value pair.

Speaker 1: 4:27

Unfortunately, because the internet is so large and there's so many types of domains and domain names, it gets a little more complicated than that, and if you remember our episodes on databases, then your red flags are probably already popping up. But, benny, I can hear you saying the internet serves multiple exabytes worth of data a day. So how can databases be strong enough to handle all this load quickly? And again, as I talked about before, it simply can't, not with just a simple key value pair. Dns is still one of the biggest bottlenecks of searching the web of the biggest bottlenecks of searching the web, but luckily for us, we aren't serving exabytes worth of data more along. A fractional percentage of that in honestly, the worst case. However, the use case for how the internet itself uses DNS is not that different from how we would actually use it to design a system to communicate with each other.

Speaker 1: 5:25

I've used the term DNS infrastructure a few times now and it's important that we spend time digging into it. It's the very heart of DNS and will be the most important part of this episode. But once you understand how DNS infrastructure works, you can get a better understanding of how it should work and when it should come into building a more robust system. So the four high-level parts of DNS infrastructure are your DNS servers, your resource records, caching and finally, what's called the DNS hierarchy. Dns servers are pretty much exactly what they sound like. They're the main servers responsible for the management of DNS data for a specific domain. Under the DNS server umbrella, there's a few types that are actually important to talk about. Recursive resolvers, for instance, are the first step when the infrastructure itself receives a query. You can think of them sort of as the gateway server that either sends back data from the cache or looks in each of the other types of DNS server to send back the correct information. If the data is not in the cache, the resolver will look for it in the root name server. That's its first stop along the whole trail here.

Speaker 1: 6:55

The root name server's main responsibility is to take that web address, like googlecom, and return a top-level domain server in which the request should be forwarded to. Top-level domains are simply the last part of a web address. If it's googlecom, the top-level domain is com. If it's wikipediaorg, the top-level domain is org, etc. Etc. When a request comes in and it reaches the root name server, it will simply just look at the top level domain and then the IP of the top level domain server that handles those top level domains. So to put it more simply, if googlecom comes in, it looks and it says, okay, this is dot com, so you're going to the, the server that handles just dot com. So there's probably multitudes of these servers. So there's probably, you know, any number of dot com top level domain servers that have to hold all these things you know replication, things like that but this main root name server will find out which IP is the best and send the request there for that top level domain server to then do something with that information.

Speaker 1: 8:19

Once the resolver passes that request to the top level domain server, it will handle that information for those specific top level domains. When a request reaches it, the TLD server will respond with details about an authoritative server, which will be the final step on the request journey until it's returned to the original caller outside of the DNS infrastructure. And an authoritative server handles specific information for domain names. If, for example, again, we take googlecom, google is the domain name in this instance the authoritative server will have information specifically for Google and respond in kind with all the information needed for the original DNS query. Again, it's the difference between googlecom and googleorg. If we send googlecom, that will go to a top-level domain server that handles coms. It will then look up Google in that server and then return the information, whereas if we send googleorg, it sends us to a different top-level domain server which then returns different information for googleorg and then, finally, the resolver will simply respond back to the browser or the original call that made the request, with all of the IP information.

Speaker 1: 9:49

Diving deeper into what happens in an authoritative server, we need to talk about DNS records or zone files, but before we do that, we need to establish what a DNS zone is and why DNS zones are important. Dns zones, at their core, help delegate the responsibility of distributing all the DNS query load. They are managed usually by some sort of entity that is usually an organization or some sort of system administrator. They can contain multiple domains and subdomains, and for each authoritative server there can exist multiple zones. So to try and paint a better picture, let's use an example like Google.

Speaker 1: 10:40

We talked about Googlecom, which would probably live in a single zone. It's very large, there's a lot of queries happening, but what about subdomains, things like docsgooglecom or drivegooglecom? In fact, at the time of writing this, google has over 50 subdomains that are still technically under the same umbrella. For their smaller domains, they might have a few subdomains in a specific zone, while the bigger ones might have their own zone and need their own administration. And if Google is smaller, they might have all of these zones on a single authoritative server, right? So if you think about, a single authoritative server can have multiple zones. It can have a single zone. For something like googlecom, which gets hit with multitudes of queries every millisecond, you would probably have a single zone on a single authoritative server and then have a bunch of authoritative servers that are just copies of that original, but for something a lot smaller. Within Google's subdomain, you could have a few different things in a zone and then you can even have multiple zones on a single authoritative server. It just depends on the amount of query load that it needs to handle. Server. It just depends on the amount of query load that it needs to handle.

Speaker 1: 12:06

So what are zone files or DNS records? They're simply just plain text files that sit within the authoritative server and its contents offer all the zones within that server and then all the domains that sit within those zones. It also contains a special record called the start of authority record, which includes contact information for the specific administrator for every zone, right? As I said, usually either a system administrator or some sort of organization is responsible for these zones, so there has to be some sort of record that says if things are failing or things aren't right, contact me because things are not good. But for a definitive list of all the different types of records that can exist on a server, I can't recommend CloudFare's excellent documentation enough, and I'm actually going to link that down below in the show notes in case you want to read more and explore more.

Speaker 1: 13:03

And why am I spending all this time talking about DNS? What good does it do to spend all of this time learning about it? Well, one reason is it's important when building a system to understand how that system communicates with the outside world, and that's not just from a knowledge perspective, it's also from a security perspective. But, honestly, a much bigger reason not bigger and important security is always the most important thing but bigger, in the sense of context of this podcast is that it's known as a microservice discovery pattern. Service discovery is simply the ability for your system to automatically locate new services that appear on your network, and with microservice architecture, which is always changing and always scaling, this is invaluable, and the reason is is dynamically finding new services is challenging, but forcing your application to do it manually is not only frowned upon, but it's very, very difficult and time consuming. Your discovery patterns are always going to be more important.

Speaker 1: 14:20

And when it comes down to service discovery, there's two main patterns that you can use. The first is client, the second is server side. They work pretty similar but with a distinguishable difference that I will dissect for you now. So for client side discovery, the way it works is pretty straightforward, with the service calling a service registry and then sends that request to a specific service. We'll talk more about the service registry in just a bit, but for now, understand that it works a lot like the DNS infrastructure we talked about before. It's a phone book for services to use to look up web addresses for a certain other service in your application.

Speaker 1: 15:06

The high-level flow of client-side discovery is that the client searches for the service registry, chooses a suitable service, then makes the call to that service. One of the key downsides of this pattern is that it takes two calls to reach the intended service. Key downsides of this pattern is that it takes two calls to reach the intended service one to the actual service registry and then the following to the actual service that the service registry responds with. But on the other side of the coin, because everything is coupled together, this pattern is a lot easier to implement. One of the most popular implementations of client-side discovery is Netflix's Eureka. That works as basically a REST API layer to your AWS instances. So basically, you have an instance, you spin it up on AWS dynamically, it can scale for you and then Eureka can actually just with the call a normal REST call actually dynamically find that service for you.

Speaker 1: 16:05

For server-side discovery, the client needs to know nothing about the service registry. Instead, the request is sent to an external router which will search for the service registry and just forward the call to the correct service One call. And just forward the call to the correct service One call. You just call the router. The router sends it to the service registry and then forwards it to the actual service itself. If you've ever used AWS Elastic Load Balancer, then you've already used server-side discovery, maybe without even knowing it, but with the extra layer of security that also comes that burden of having to set up and manage the server discovery on your own. So to recap, a client side discovery pattern will send a call to a service registry that sends back an IP of a specific instance that is free, whereas a server-side pattern will send the call to a router that forwards the call to a service registry that then sends back to the router and the affords that call to the actual free service. The difference between the two besides the client side being two calls and the server side being one call is because the service registry has to be maintained by you on the server side.

Speaker 1: 17:38

What is a service registry? It's the backbone of the service discovery model. It can be thought of, as mentioned before, as a phone book for all the different types of services that are important for your application. What it actually is is a database that holds the locations of all the services that are currently available for use, holds the locations of all the services that are currently available for use In both server side and client side. The services, when they're spun up or created, are automatically added to the registry and when they're terminated, they're actually automatically removed. If you remember our database episode when we talked about replication, the service registry is a prime example of this. It uses replication on a cluster of servers that holds your services and can even provide heartbeat checks to remove those services as they are spun up or spun down. If you're not familiar with what a heartbeat check is, imagine just a script that periodically sends a request to a server and just waits for a 200 to come back. If anything other than a 200 comes back like a 500, or any sort of status code that says something's wrong with this machine, it's down, it gets removed from the registry and it's handled outside of this scope.

Speaker 1: 19:05

As for how service discovery is actually implemented, there's actually three popular forms as of writing this. Despite the fact that it may seem impossible to execute yourself. Using the tools we learned in this episode, I believe you have the ability to make the correct choices on how to design and build your own. The first approach for service discovery is DNS-based, which, unsurprisingly, utilizes DNS libraries to prop up your services. Using a proxy tool like Nginx, you can actually perform heartbeat checks for services, as we talked about before, to ensure your services are available. When a service is created, the service is added to the DNS zone file and can be used to do a lookup for all available services. Then, if a service is terminated, it will be removed from that zone file and, in result, removed from the pool of service instances.

Speaker 1: 20:04

The big win with DNS-based service discovery is that it's language agnostic. It can be executed within any programming language. The major downside is in between those heartbeats, you may not have a real-time view of all the instances that are available. So if there's too much time happening between your heartbeats, if your heartbeat is at five seconds and one of your servers goes down at three seconds, that's two seconds worth of time that an instance is not available. It is in your pool and, as we talked about in some of the older episodes, two seconds can be a lifetime for a lot of industries, especially retail.

Speaker 1: 20:52

The second approach for service discovery is the key value store approach. In this approach, you can use a popular tool like Apache Zookeeper and that will act as a centralized service discovery application. It then uses a sidecar process to actually configure the proxy and fetch the result. The downside is that the sidecar process actually requires very specific tuning for every microservice that is added to your pool. And our final approach is the specialized service using a sidecar. In this approach, you can use a library to communicate with pre-existing discovery solutions, like Netflix's Eureka, and then again have that proxy on the side with all the fine-t tuning for each of the services, as we talked about before. In the end, whether it's orchestrating the mini pipes for the internet or simply wiring up your microservices to communicate in an automated fashion, dns is all around us, acting as a beautiful conductor. It is quite literally vital to understanding how our systems work, how to make them better and, honestly, I encourage you to learn more about the different patterns and challenge yourself on what is best for which edge case.

Speaker 1: 22:17

I want to give a huge, special thank you to Klavian S, florian B and Nathaniel S for your Patreon subscriptions. You guys rock. It means the world to me. I'm still working on rewards I can offer, but for now, if there's anything I can specifically research or talk to you about, definitely reach out. My current idea is to shift from talking about the different types of system design, applications and products and go into actually solving some companies, some more of the popular interview tactics and what to do and how to solve specific system design questions. If that's the case, that's probably what we will start with next episode and, for the people subscribed to the Patreon, I'm going to give it to you a week early. I can't promise that's going to be next week or the week after, but as soon as it's done, you're going to get it first and then everyone else will have to wait around a week.

Speaker 1: 23:23

So definitely, if you're interested, check out the Patreon and feel free again to message me. Email me any feedback you might have for the podcast or what you might like to hear more of, if that jazzes you up. If you want to hear more about the most common types of system design questions and I can talk about how to think about it, how to approach it and what the best use case will be for those, then, yeah, definitely drop me a line. You can email me at learnsystemdesignpod at gmailcom. You can reach me out on the Patreon, the Twitter or even the Discord. That's probably the quickest way to reach me. Yeah, if you would like to support this podcast, help me pay my bills again. Jump over to Patreon. Consider becoming a member. All podcasts are inspired by Crystal Rose. All music is written and performed by the wonderful Aimless Orbiter. You can check out more of his music at soundcloudcom slash aimlessorbitermusic. Check out more of his music at soundcloudcom slash aimlessorbitermusic. And with all of that being said, this has been and I'm scaling down Bye-