Network protocols and proxies for system design interviews

Network protocols and proxies are among the most fundamental building blocks of system design. And if you’re preparing for a system design interview (or just want to be more familiar with system design), then understanding these topics is a good place to start.

Below, we’ll briefly define network protocols and proxies, and then we’ll dig into the essential details that you’ll need to know about each one. Here’s what we’ll cover:

Network Protocols
Proxies
Example network protocol and proxy questions
System design interview preparation

Practice 1-to-1 with ex-FAANG system design interviewers

1. Network Protocols

Networks of computers make up everything on the internet - from local private networks enabling communication between web service components to the global public network linking services with billions of users.

Network protocols make it possible for any networked computers to talk to each other, no matter where they are or what hardware or software they’re running. They do this by establishing standard forms for sending and receiving data over the network’s physical infrastructure.

The most common network protocols are time-tested, widely used, and well understood. Knowing what these protocols do and when they are used will be a key tool to being able to understand and design technical systems.

Before we describe the specific protocols, we’ll need some context on where they fit in network infrastructure. We’re going to go over the two most common models of networking that present a framework for how internet communication works. These models are widely used to categorize protocols, hardware, and many other system components, so it’s important to understand and be able to talk about them.

1.1 Networking Models

Both of these models we’re about to discuss divide the network stack into “layers”. These layers provide increasingly complex guarantees that the next layer can build off of. This enables communications at the highest layer to deal with application-related concerns like the meaning of the data, and not hardware-related issues like data loss from faulty wires.

There are protocols at each layer of the networking models. Protocols work together by treating the output message of the previous protocol as input data, and won’t modify or interfere with it. This way each protocol can do its portion of the work to transmit data over the network, and rely on the other protocol’s guarantees without having to know how they work.

1.1.1 TCP/IP Model

TCP/IP, also known as the Internet Protocol Suite is one of the oldest networking models and greatly influenced the development of the internet as we know it. It’s named after its two primary protocols, TCP and IP. This model has four layers and associated protocols that define the abstraction:

Link Layer: protocols relevant to a local network, called a “link” or “IP network”. These computers are physically wired on the same network and don’t need a router to communicate, e.g. MAC addresses
Internet Layer: protocols relevant to connecting different IP networks, e.g. IPv6
Transport Layer: protocols for direct communication channels over the internet, e.g. TCP
Application Layer: protocols relevant to applications sending data to and from users over the internet, e.g. HTTP

1.1.2 OSI Model

The Open Systems Interconnection model (OSI model) is a well established model of the internet that is a useful conceptual tool. It has 7 layers, which allows more specificity when talking about networking than with the TCP/IP model. OSI doesn’t specify protocols, and many popular protocols don’t fit in one or more of its layers:

Physical Layer: transmission of raw data on hardware. e.g. Ethernet
Data Link Layer: establishing connection for data transfer between computers in the same physical network, e.g. MAC addresses
Network Layer: establishing connection for data transfer in packets between computers in different networks. e.g. IP
Transport Layer: transferring data with reliable quality. e.g. TCP
Session Layer: managing data transfer sessions between computers.
Presentation Layer: translating lower layer data formats for use by the application layer.
Application Layer: application-enabling functionality. e.g. HTTP

Now that we’ve gone over the TCP/IP and OSI models, let’s go into how some of the most commonly-used protocols work, and how they fit into these models.

1.2 Protocols

1.2.1 IP

The Internet Protocol (IP) is the key protocol that allows computers in different physical networks to communicate with each other. It’s defined in the Internet Layer of the TCP/IP model, and corresponds to approximately Layer 3 of the OSI model.

IP defines and works with the fundamental data unit of a packet. It also provides addressing, in the form of IP addresses, so packets can be correctly routed from their source to destination.

An IP packet consists of a header and some data. The IP header contains information including the source and destination address. The data is formatted and contains whatever is useful for the next layers.

1.2.2 TCP

The Transport Control Protocol (TCP) manages reliability of data transferred with IP. TCP is defined in the Transport layer of the TCP/IP model, and corresponds to approximately Layer 4 of the OSI model.

TCP works by first establishing a connection between the client and server, and then transferring data. It builds on IP to add guarantees that data messages are delivered reliably, in order, and checked for errors.

If the application needs faster data transfer and doesn’t require a confirmed connection it can use the similar User Datagram Protocol (UDP) instead. UDP works at the same layer as TCP, but has no guarantees about data delivery or ordering, which works well for situations like broadcasting.

TCP is a fast and reliable protocol, and as such many other protocols build off of it, like TLS encryption and WebSockets.

1.2.3 HTTP

The Hypertext Transport Protocol (HTTP) allows applications to view and modify data over the network. HTTP corresponds to the Application layer of the TCP/IP model, and Layer 7 of the OSI model.

To use HTTP, and it’s secure variant HTTPS, a client makes a coded request to a server which sends back a coded response. HTTP requests and responses are divided into the header which contains metadata about the request and the body which contains data in some specified format (e.g. JSON).

HTTP uses uniform resource identifiers (urls) for users to specify what data they’re trying to access. For example, you’ll type in `http://igotanoffer.com` to make a request from your computer to view our website, which is made of HTML, CSS, and JavaScript files, hosted on our servers.

The codes included in HTTP requests and responses convey information about the kind of request or response. HTTP methods (verbs) specify what kind of request is being made. We won’t list all 9 methods here, but the key ones to know are:

GET - a request to read data
POST - a request to create the data in the body
PUT - a request to create or update data at a specified url with the data in the body
DELETE - a request to delete the data at the specified url
OPTIONS - a request for a listing of the HTTP methods a server supports

HTTP status codes that indicate what kind of response has been sent back. They are 3 digit codes that are grouped by the first number in the code. Each code has a corresponding “reason phrase” to make human interpretation easier.

1XX - informational response e.g. `102 Processing`
2XX - successful response e.g. `200 OK`
3XX - redirection response e.g. `302 Found`
4XX - client error response e.g. `404 Not Found`
5XX - server error response e.g. `500 Internal Server Error`

Other features of HTTP include sessions, which can be established and maintained either server side, or client side with HTTP cookies. HTTP also supports authentication in a variety of ways.

2. Proxies

A proxy is a server that sits between a client and application server to provide some intermediary service to the communication. There are two kinds of proxies that provide different services: forward proxies and reverse proxies.

2.1 Forward Proxies

Forward proxy

A forward proxy sits between a pool of clients and the public internet. The goal of a forward proxy is to protect the particular client pool by filtering outgoing requests and incoming responses.

The common use cases for forward proxies are:

Enforcing “terms of use” on a network
Blocking malicious websites
Anonymizing network traffic by using the IP address of the proxy instead of the client

For example, a school network might decide to block requests going out to certain social media websites. Alternatively a business network might try to mitigate phishing attacks by not allowing employee requests to known malicious domain names.

2.2 Reverse Proxies

Reverse proxy

A reverse proxy sits between the public internet and a pool of servers. Because of their location in the system as an intermediary, reverse proxies can provide a number of services, including:

Anonymizing the cluster servers
SSL termination
Load balancing
Caching
Filtering requests
Attack prevention (e.g. DOS detection)

For example, if a company wanted to expose a public API for querying data, but not modifying it, they could filter out any requests that used an HTTP verb other than GET before passing the requests on to the servers that actually process and generate the responses.

As another example, a service could use a reverse proxy to handle TLS termination (the description of HTTPS requests) so that the application servers don’t have to handle encryption/decryption. The proxy would then pass on the requests to the servers within a private network so the communication is still secure.

3. Example network protocol and proxy questions

The questions asked in system design interviews tend to begin with a broad problem or goal, so it’s unlikely that you’ll get an interview question entirely about network protocols or proxies.

However, you may be asked to solve a problem where these topics will be relevant. As a result, what you really need to know is WHEN (or IF) you should bring them up and how you should approach them.

To help you with this, we’ve compiled the below list of sample system design interview questions, where network protocols or proxies are relevant.

Design Twitter (Read the answer)
Design a highly-scalable system (Read the answer)
Design a Web Crawler (Read the answer)
TCP vs. UDP (Read the answer)

4. System design interview preparation

Network protocols and proxies each describe one element of a broader system. But to succeed on system design interviews, you’ll also need to familiarize yourself with a few other concepts. And you’ll need to practice how you communicate your answers.

It’s best to take a systematic approach to make the most of your practice time, and we recommend the steps below. For extra tips, take a look at our article: 19 system design interview tips from FAANG ex-interviewers.

Otherwise, you can prepare by following the steps below.

4.1 Learn the concepts

There is a base level of knowledge required to be able to speak intelligently about system design. To help you get this foundational knowledge (or to refresh your memory), we’ve published a full series of articles like this one, which cover the primary concepts that you’ll need to know:

We’d encourage you to begin your preparation by reviewing the above concepts and by studying our system design interview prep guide, which covers a step-by-step method for answering system design questions. Once you're familiar with the basics, you should begin practicing with example questions.

4.2 Practice by yourself or with peers

Next, you’ll want to get some practice with system design questions. You can start with the examples listed above, or with our list of 31 example questions.

We’d recommend that you start by interviewing yourself out loud. You should play both the role of the interviewer and the candidate, asking and answering questions. This will help you develop your communication skills and your process for breaking down questions.

We would also strongly recommend that you practice solving system design questions with a peer interviewing you. A great place to start is to practice with friends or family if you can.

4.3 Practice with ex-interviewers

Finally, you should also try to practice system design mock interviews with expert ex-interviewers, as they’ll be able to give you much more accurate feedback than friends and peers

If you know someone who has experience running interviews at Facebook, Google, or another big tech company, then that's fantastic. But for most of us, it's tough to find the right connections to make this happen. And it might also be difficult to practice multiple hours with that person unless you know them really well.

Here's the good news. We've already made the connections for you. We’ve created a coaching service where you can practice system design interviews 1-on-1 with ex-interviewers from leading tech companies. Learn more and start scheduling sessions today.

Learn more about system design interviews

This is just one of 9 concept guides that we've published about system design interviews. Check out all of our system design articles on our Tech blog.

Network protocols and proxies: system design interview concepts (1 of 9)