Understand distributed systems architecture

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).

Derive why distributed systems cannot rely on synchronized physical clocks for ordering, using logical reasoning about network delays.

Define and differentiate between linearizability, sequential consistency, causal consistency, and eventual consistency, providing practical examples for each.

Analyze the trade-offs defined by the CAP theorem and its extension, the PACELC theorem, using real-world database systems as examples.

Compare the roles and high-level mechanisms of consensus algorithms (e.g., Paxos, Raft) in providing fault-tolerance and strong consistency.

Define network partitions, node failures, and Byzantine failures, providing concrete examples of how each could manifest in a high-stakes financial system.

Implement a synchronous request-response pattern in Python for a simplified trading scenario, demonstrating robust handling of network timeouts and service unavailability.

Implement asynchronous message passing between services using a message queue (e.g., RabbitMQ) for the same trading scenario.

Compare the trade-offs between synchronous and asynchronous communication patterns in terms of latency, throughput, coupling, and fault tolerance.

Explain the role of idempotency in distributed systems, using examples from payment processing to illustrate the risks of non-idempotent operations.

Implement client-side retry logic with exponential backoff and jitter for handling transient failures in service communication.

Analyze the system-wide implications of at-least-once, at-most-once, and exactly-once delivery semantics.

Install and run a RabbitMQ instance locally using Docker.

Programmatically declare a RabbitMQ exchange and queue, and bind them to implement a pub/sub pattern using a Python client library.

Implement publishers and subscribers in Python that communicate via the configured RabbitMQ topology.

Configure the competing consumers pattern in RabbitMQ to enable parallel processing of messages from a single queue.

Implement a dead-letter queue (DLQ) mechanism to handle message processing failures gracefully.

Explain the architectural trade-offs between queue-based (e.g., RabbitMQ) and log-based (e.g., Kafka) message brokers.

Identify key metrics for monitoring message broker performance (e.g., queue depth, consumer lag) and diagnose common bottlenecks.

Explain the core principles of event sourcing and how it differs from traditional state-oriented persistence.

Design aggregate roots and domain events for a financial scenario from your experience (e.g., FX trade lifecycle).

Implement event replay to reconstruct the current state of an aggregate from its historical event stream.

Implement snapshots for an aggregate to optimize state reconstruction performance for long-lived objects.

Explain common strategies for event schema evolution (e.g., upcasting, lazy migration) and their trade-offs.

Implement an upcaster function in Python to transform an older event version into the current version during state reconstruction.

Analyze the benefits and drawbacks of event sourcing, identifying use cases where it is and is not appropriate.

Analyze the Command Query Responsibility Segregation (CQRS) pattern, explaining when its complexity is justified.

Design separate write (command) and read (query) models for the financial scenario modeled in the previous module.

Implement a projection that consumes an event stream to build and maintain a denormalized read model.

Address eventual consistency between write and read models, including strategies for communicating data staleness to clients.

Define the API contract for a generic event store service, including methods for appending events and retrieving event streams.

Implement optimistic concurrency control in an event store service by using aggregate version numbers to detect write conflicts.

Compare the trade-offs between different persistence technologies for implementing an event store (e.g., relational DB, document DB, specialized event store).

Compare the Python 'eventsourcing' library with a manual implementation approach based on criteria such as developer experience, persistence options, and maintainability.

Set up the 'eventsourcing' library with a message broker integration for event notification.

Implement aggregates, commands, and events for a sample application using the framework's abstractions.

Configure the framework to use a separate persistence service (e.g., PostgreSQL) for event storage.

Implement projections and read models that are driven by the framework's notification system.

Write unit and integration tests for an event-sourced application using the framework's testing utilities.