Identifying Distributed System Characteristics in Familiar Platforms

Hello! Welcome to your first lesson in the Distributed Systems Architecture course.

Given your goal of mastering distributed systems architecture, this first module will build the foundational knowledge you need. We'll start by defining what a distributed system is and exploring its fundamental properties.

This lesson specifically addresses the first learning outcome: Analyze a familiar system from your experience (e.g., Revolut's FX trading platform) to identify characteristics that make it distributed (concurrency, lack of global clock, independent failures).

We will break down these three core characteristics and then apply them to a system you know well, like the FX trading or settlement platforms you built at Revolut. This will provide a concrete, practical anchor for the more abstract concepts we'll cover throughout the course.

1. What is a Distributed System?

At its core, a distributed system is a collection of independent computers that appears to its users as a single, coherent system. These computers, often called nodes, communicate over a network to coordinate their actions and achieve a common goal. The complexity of this coordination is hidden from the end-user.

To get a more formal definition, please watch the first two minutes of the following video.

Think about the Revolut app. When a user executes an FX trade, they interact with a single interface. Behind the scenes, however, it's highly likely that multiple services are working together: a service to check the user's balance, a service to fetch real-time exchange rates, a service to execute the trade with a liquidity provider, and another to update the user's account ledgers. This is the essence of a distributed system: a unified experience built from disparate, coordinating parts.

2. The Three Defining Characteristics

For a system to be considered distributed, it must exhibit a few key properties. The video you just watched briefly mentioned them. We will now explore the three most important ones in detail: concurrency, the lack of a global clock, and independent failures.

a) Concurrency

Concurrency in a distributed system means that multiple processes are executing simultaneously on different nodes. These processes can, and often do, interact with each other.

In the context of an FX trading platform, concurrency is rampant. While your trade is being processed, thousands of other users are concurrently:

• Requesting price quotes.
• Placing their own orders.
• Checking their account balances.
• Making withdrawals or deposits.

Each of these actions is handled by processes that run in parallel across the system's infrastructure. The system must be designed to handle these concurrent operations safely and correctly, ensuring, for example, that a user can't spend the same money twice in two simultaneous trades.

b) Lack of a Global Clock

This is one of the most fundamental and challenging aspects of distributed systems. Each computer in the system has its own physical clock, but there is no single, global clock that all computers can agree on.

Why is this a problem? Because of network latency. A message sent from node A to node B takes an unpredictable amount of time to arrive. If node A timestamps an event with its local time and sends it to B, B cannot know for sure how its own local time relates to A's. Furthermore, physical clocks on different machines drift at different rates.

This makes ordering events across the system incredibly difficult.

As the article explains, real-world systems are best described as partially synchronous. Most of the time, network delays are small and predictable. But we must design for the times they are not—when a network switch is overloaded, a garbage collection pause freezes a service, or a transatlantic cable has a momentary glitch. In these moments, our "synchronous" assumptions break down.

A classic problem that illustrates this is generating globally unique, time-ordered identifiers.

In financial systems, the order of operations is critical. If two traders submit an order to buy the last available unit of an asset, the system must have an unambiguous way to determine who was first. Relying on wall-clock timestamps from different machines is not a reliable way to do this. This is why we will later explore concepts like logical clocks.

c) Independent Failures

In a monolithic, single-computer system, if the computer fails, the entire system fails. In a distributed system, components can fail independently. One server might crash due to a hardware fault, another might become unreachable due to a network partition, and a third might have a software bug causing it to behave incorrectly.

A well-designed distributed system must be able to detect and tolerate these partial failures, continuing to operate (perhaps in a degraded capacity) without catastrophic failure.

The article outlines three key failure models:

• Crash-stop: A component stops and never comes back. A stateless web server that can be easily replaced fits this model.
• Crash-recovery: A component crashes but can be restarted, potentially recovering its state from persistent storage (like a database recovering from its write-ahead log). This is the most common model for stateful services.
• Byzantine: A component behaves arbitrarily or maliciously—sending corrupt data, lying about its state, etc. This is the hardest failure to handle and is critical in trustless environments like public blockchains, or systems under security attack.

For the Revolut FX platform, you can imagine many independent failure domains. The service that provides live price feeds could fail, but this shouldn't prevent a user from checking their past transaction history. The risk management service might crash, which should ideally block new trades but not affect the settlement of already-executed trades.

Application and Analysis

Now, let's synthesize these concepts by applying them to a system you're intimately familiar with. Think about the FX trading platform you worked on at Revolut.

Please take a few minutes to answer the following questions. There are no right or wrong answers; the goal is to connect the theory to your practical experience.

1. Concurrency: Describe two or three distinct user actions that could be happening concurrently on the platform. What potential conflicts could arise from this concurrency (e.g., related to a user's cash balance)?
2. Lack of a Global Clock: Imagine two customers, one in London and one in New York, submit market orders for the same currency pair at the exact same instant according to their phone's clock. Why is it impossible for the system to use those times to decide which order to process first? What kind of problems would arise if the system simply used the local server timestamps where the requests landed?
3. Independent Failures: Identify three distinct microservices or components that likely existed in the platform's architecture (e.g., User Authentication, Price Feed, Order Execution, Risk Engine, Account Ledger). For each component, describe what would happen to the overall system if that single component experienced a "crash-stop" failure. Which failures would be most critical?

This exercise is the main task for this lesson and directly fulfills the learning outcome.

Conclusion

In this lesson, we established a foundational understanding of distributed systems.

Key Takeaways:

• A distributed system is a set of independent nodes that work together over a network, presenting a single-system illusion to the user.
• They are defined by three core characteristics:
  • Concurrency: Multiple operations execute in parallel across the system.
  • Lack of a Global Clock: There is no single source of truth for time, making event ordering a fundamental challenge. Real-world systems are best modeled as partially synchronous.
  • Independent Failures: Components can fail in isolation, and the system must be designed to be resilient to these partial failures.

You now have the basic vocabulary and conceptual framework to analyze and discuss distributed architectures.

Preview of the Next Lesson:
We've seen that the lack of a global clock makes ordering events difficult. In the next lesson, we will dive deeper into this problem. We will formally explore why physical clocks are insufficient and introduce the foundational concept of logical clocks (specifically, Lamport timestamps) as a way to establish a causal ordering of events in a distributed system.