On Track with Phoenix Tracker
Phoenix Tracker solves the problem of tracking processes and metadata about those processes across a cluster of servers. This sounds like an easy problem, but it’s challenging due to the types of conflicts that occur when replicating information between servers. We’ll use Tracker in our application to track each connected
ShoppingCartChannel process, along with metadata for each cart. Before we add Tracker to our application, let’s go over it and how to use it.
Tracker uses a particular type of data structure to replicate its information across a cluster. We’ll go over this data structure and look at what guarantees it provides. We’ll then cover different use cases for Tracker. Finally, we’ll set up a basic Tracker to demo how it works.
Let’s get started by looking at how Tracker works.
Phoenix Tracker’s design
Phoenix Tracker maintains accurate and timely presence lists across a cluster of servers. It does so without having a single authoritative source (like a database)—each server contributes to the known state. Time is not our friend when it comes to the distributed state, making this problem challenging. The first pass at this problem—dispatching changes to a set—would quickly run into many edge cases. There would be conflicts in data, lost updates, and inefficient performance. Phoenix Tracker uses a data structure called a
A CRDT provides replicated states across multiple servers with independent and concurrent updates to the underlying data—each data structure can be updated without asking other copies for permission. There are many different types, but Phoenix Tracker uses an
The OTP process structure of Tracker is more relevant to us. The following figure shows the multi-shard process structure that Tracker uses: