Gain insights into distributed systems, learn architectural patterns like replication and sharding, and explore Apache Spark and Druid to design and develop effective distributed applications.

data_eng.tar.gz

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

AWS_DEFAULT_REGION

Apache_Druid

Mapreduce

aws_load_balancer

service_sharding

cqrs

apache_spark

apache_kafka

Gone are the days when monolithic applications were the norm. Most applications that we use today are too complex for that type of construction. Instead, most applications that appear as a single unit are actually built as a collection of inter-operating but independent computational components. Developers are expected to have mastery over a programming language or two. Moreover, they should also know the basics of distributed systems in order to succeed.

In this course, you’ll learn what a distributed system is, followed by the challenges unique to distributed systems. You’ll cover popular architectural patterns for achieving targets like replication and sharding. You’ll finish with a study of two popular distributed systems: Apache Spark and Apache Druid.

With the knowledge gained through this course, you’ll be able to design and develop distributed systems. You’ll be able to make optimal design and architectural choices based on the application requirements.

Introduction to Distributed Systems for Dummies

# How to achieve availability in distributed systems?

This is somewhat answered already—add redundancy in your system.

>Build your system in such a way that when things go wrong, redundant resources can handle the load and continue serving your users.

In this context, let's introduce the concept of **SPoF**.

> **S**ingle **P**oint **o**f **F**ailure (SPoF) in a distributed system means a component that can bring the entire system down if there is any failure in the node itself.

For example, your home router can be a SPoF. If the router is down, you lose access to the internet.


To build an available system, you need to avoid any possible SPoF so that the system can continue to function even when there are failures.


# Setting up expectations 

So far we have seen how critical it is for a system to be resilient when it comes to faults, as well as how important it is for them to operate correctly in adverse scenarios. This is why distributed systems pursue properties like availability and reliability.

But the question is, how far should you go as a distributed system owner?

Let's think of availability.

Assume My Cool App has 5 nodes running the server program. Due to well-designed architecture, the system is capable of losing 1 node or 2 nodes. What happens if 3 nodes crash? What if all the nodes crash at the same time?

>Somewhere down the line, you need to set expectations.

If in your system, all nodes crash, no algorithm can help to tolerate this fault. It does not really make sense to tolerate faults for an arbitrary number of nodes, or resources. Because let’s face it, no matter how good the hardware you buy is, time kills everything. They will _eventually_ break. (Though all nodes breaking at the same time is a fairly rare event, unless you have some software bug that causes cascading failures.)

The point is, things will go wrong. You can never guarantee that they won't. When you operate My Cool App in production, things will break and outages will happen. 

Even systems owned by Google or Amazon face outages.

So in practice, distributed systems define some set of expectations and communicate them to their clients. That's where the availability percentage measurements are used. In the case of My Cool App, you can define that the availability will be 2-nines ($99%$).

# How to define expectations

Let's talk about three terms: SLA, SLO, SLI.

## Service Level Agreement (SLA)

>SLA is an agreement between the system and its clients on specific requirements, for example, response time or availability.

As a system owner, you can set up an agreement with your clients that:

- The system will have at most 2 days of downtime over a year ($99.5%$ availability).
- The system will respond to client requests within $100ms$.

When your system makes an agreement with such objectives, this is called a Service Level Agreement (SLA).

In the tech industry, such agreements are common between a vendor and a paying customer. Say, for example, Visa can come to an agreement with one of its paying customers that the system will be up $99.99%$ time. This objective will be part of the SLA. If the agreement is breached, there will be some actions taken based on the agreement. For instance, Visa could pay the client as a penalty.

## Service Level Objective (SLO)

Individual promise in SLA is called an SLO. For example, one of My Cool App’s SLOs could be loading users’ feeds within $200ms$.

Similarly, Visa could have an SLO of processing each transaction within $2s$.

## Service Level Indicators (SLI)

SLA and SLO are agreements and promises between a service and its clients. SLI is the actual measurement in reality.

For example, if Visa promises its clients an uptime of $99.99%$, and in reality, the uptime is $99.95%$, the SLO is 4-nines, but SLI is 3-and-a-half nines.

In the real world, it's not straightforward to perfectly stick to the SLAs and act upon them. Generally, the service and its client tune their expectations over the course of time.

# Key takeaways

- In the real world, systems consider availability a must have.
- How far developers will go to ensure availability depends on business needs.
- Large systems try to be available as much as possible. For smaller systems, going for two- or three-nines of availability could be more than enough.
- At some point, trying to be more available may not be worth the effort or the cost incurred. Because increasing availability requires more components in the system to failover when necessary, and that requires money—not to mention the engineering efforts involved.
- SLA, SLO, and SLI can help set expectations for a system from consumers’ perspectives. As an owner, this will also help you to focus on the right direction for your system-level improvements.

Build an understanding of how availability is achieved in distributed systems.

Introduction

What Distributed Systems Achieve for Us

Data in Distributed Systems

Communication Between Nodes

Data Processing in Large Scale

Distributed System Architectural Patterns

Case Study 1: Apache Spark

Case Study 2: Apache Druid

Conclusion

Achieving Availability

How to achieve availability in distributed systems?