Think local: Reducing coordination and improving performance in your distributed systems

Description

You build distributed systems to maintain availability and improve performance. However, as soon as distributed state is thrown into the mix, you have to start thinking about the performance costs of accessing that state and keeping it current. Many of the worst problems concern the need for coordination across nodes and across systems within a node. Drawing on the lessons he’s learned working on Wallaroo, a high-performance, open source framework for building stateful distributed applications, John Mumm outlines strategies for avoiding coordination and relying on local knowledge wherever possible.

John outlines when you might need to rely on coordination in a distributed system. Coordination has its advantages, but it also normally entails costs regarding availability, throughput, latency, and scalability. Seen from one perspective, the question of whether you need to coordinate boils down the question of whether you need to share global knowledge. For this reason, John looks more closely at what knowledge means in a distributed system and how, given different system requirements, you can make a choice regarding how much you should rely purely on local knowledge, allowing you to avoid coordination.

You’ll examine the ways you might think local in your own distributed systems, drawing on John’s experience building Wallaroo. In particular, you’ll look at using actors as your units of concurrency, avoiding the kinds of coordination that arise from sources ranging from locks to stop-the-world garbage collection; relying on state entities as transaction boundaries, thereby avoiding the coordination involved in distributed transactions; and relying on in-memory application state in order to avoid coordination with external data stores. Each of these strategies involves trade-offs, so you’ll need to think carefully about your own particular use cases and requirements.