Distributed System Design with STAR
Introduction to Distributed Systems
Working Together, Separately
Think about your favorite social media app. When you post a photo, it feels like you're interacting with one single, massive computer. But behind the scenes, your photo, likes, and comments are handled by hundreds or even thousands of computers working together. This is a distributed system.
Distributed System
noun
A collection of independent computers that appears to its users as a single coherent system.
In a distributed system, these separate computers—often called nodes—don't share memory or a processor. They are completely independent machines. Their only way to communicate and coordinate is by sending messages to each other over a network. To an outside user, this complex coordination is invisible. You just see the app working seamlessly.
A key feature is the lack of a global clock. Each computer has its own internal clock, and there’s no single source of truth for what time it is across the system. This makes ordering events a major challenge.
Why Go Distributed?
Building a distributed system is complicated, so why do it? There are two huge advantages: scalability and fault tolerance.
Scalability is the ability of a system to handle a growing amount of work. With a distributed system, if your app becomes more popular, you don't have to buy a single, bigger, and much more expensive supercomputer. Instead, you can just add more standard, cheaper computers to the group. This is called horizontal scaling.
Think of a grocery store. If the lines get too long, you could train your one cashier to be twice as fast (vertical scaling), but that's difficult and has limits. It's much easier to just open another checkout lane and hire another cashier (horizontal scaling). Distributed systems let you keep adding lanes.
Fault Tolerance means the system can continue operating even if some of its components fail. If one computer in a ten-node cluster crashes, the other nine can pick up the slack. For the user, the service might be slightly slower, but it won't go down entirely. This creates a highly available and reliable service.
In our grocery store analogy, if one cashier gets sick and goes home, the other cashiers can still serve customers. The store stays open. A single, monolithic system is like a store with only one cashier. If they leave, the entire store shuts down.
The Hard Parts
These benefits come with significant challenges. Managing a fleet of cooperating computers is much harder than managing a single machine.
Controlling concurrent data access in monolithic systems is already challenging, but the problem is exacerbated in distributed systems.
Two of the biggest hurdles are consistency and coordination.
Consistency ensures that all the nodes in the system have the same data at the same time. If you update your profile picture, you want all your friends to see the new picture, not the old one. But since data has to be copied across the network to different nodes, there's always a delay. Ensuring every user sees a consistent view of the data is a complex problem.
Coordination is about getting the nodes to agree on something, like the order in which operations should happen. Since there's no global clock, and network messages can be delayed or lost, it's very difficult to determine the precise sequence of events across the system. This makes everything from financial transactions to data replication tricky to get right.
These foundational ideas of scalability, fault tolerance, and the challenges of consistency and coordination are the starting point for understanding how modern, large-scale applications are built.