This is a summary of the book — Design and Build Great Web APIs by Mike Amundsen. Below are the links to each chapter so as to keep it short and simple to read. Getting Started Chapter 1: Getting Started with API First Adopting API-First principleaditilonhari.medium.com Chapter 2: Understanding HTTP, REST and APIs HTTP, short for hypertext transfer protocol, is an open standard to make sure machines talk to each other over the…aditilonhari.medium.com

So far, this book has been mostly about describing things as they are at present. In this final chapter, we will shift our perspective toward the future and discuss how things should be. If you have a problem such as “I want to store some data and look it up…

One big assumption we made throughout Chapter 10 was that the input is bounded — i.e., of a known and finite size — so the batch process knows when it has finished reading its input. In reality, a lot of data is unbounded because it arrives gradually over time. The…

On a high level, systems that store and process data can be grouped into two broad categories: Systems of record A system of record, also known as source of truth, holds the authoritative version of your data. When new data comes in, e.g., as user input, it is first written…

In this chapter, we will talk about some examples of algorithms and protocols for building fault-tolerant distributed systems. The best way of building fault-tolerant systems is to find some general-purpose abstractions with useful guarantees, implement them once, and then let applications rely on those guarantees. This is the same approach…

A recurring theme in the last few chapters has been how systems handle things going wrong. For example, we discussed replica failover, replication lag and concurrency control for transactions. As we come to understand various edge cases that can occur in real systems, we get better at handling them. However…

In the harsh reality of data systems, many things can go wrong: The database software or hardware may fail at any time (including in the middle of a write operation). The application may crash at any time (including halfway through a series of operations). Interruptions in the network can unexpectedly…

In Chapter 5 we discussed replication — that is, having multiple copies of the same data on different nodes. For very large datasets, or very high query throughput, that is not sufficient: we need to break the data up into partitions, also known as sharding. Normally, partitions are defined in…

Replication means keeping a copy of the same data on multiple machines that are connected via a network. There are several reasons why you might want to replicate data: To keep data geographically close to your users (and thus reduce latency) To allow the system to continue working even if…