System Design Interview Distributed Cache

Today we design a distributed cache. We will start with some simple ideas and little by little evolve our design into a fully-fledged architecture. Approach, that we highly encourage you to use during a real interview. We also will discuss several important tips along the way. As usual, let's start with the problem statement. Let’s take a look at a typical setup, a web application backed by a data store. This data store may be a database or another web service. Client makes a call to the web application, which in turn makes a call to the data store and result is returned back to the client. There may be several issues with this setup. First, calls to the data store may take a long time to execute or may utilize a lot of system resources

System Design Interview Notification Service

Welcome to the system design interview channel. Today we design a notification service. Let's start with the problem statement. In the world of web services there are many scenarios when messages need to be sent in a reaction to some event. For example, when credit card transaction amount exceeded a limit and card holder needs to be notified. Or service monitoring system encountered a large number of faults produced by API and on-call engineer needs to be notified. In more general terms, let's say there is a component called Publisher which produces messages that need to be delivered to a group of other components, called Subscribers. We could have setup a synchronous communication between Publisher and Subscribers, when Publisher calls each Subscriber in some order and waits for the response. But this introduces many different challenges: hard to scale such system when number of subscribers and messages grow and hard to extend such solution to support different types of subscribers.

System Design Interview Distributed Message Queue

Today we design a distributed message queue. First, let’s make sure we are on the same page regarding the problem statement. What is a distributed message queue? Let's say there are two web-services called producer and consumer, and they need to communicate with each other. One option is to setup a synchronous communication, when producer makes a call to a consumer and waits for a response. This approach has its own pros and cons. Synchronous communication is easier and faster to implement. At the same time synchronous communication makes it harder to deal with consumer service failures. We need to think when and how to properly retry failed requests, how not to overwhelm consumer service with too many requests and how to deal with a slow consumer service host. Another option is to introduce a new component that helps to setup asynchronous communication. Producer sends data to that component and exactly one consumer gets this data a short time after. Such component is called a queue. And it is distributed, because data is stored across several machines. Please do not confuse queue with a topic

About Home Study

Technology and Life