Registry Service is a foundational building block for distributed systems and applications that need leader election, distributed semaphores, atomic broadcast, group membership management, or a fast linearizable storage for configuration/bootstrap/etc. data.

​

Patent pending #63/584,865.

​

Service Highlights

​

• Linearizable consistency.

• Microsecond p99 server latency.

• Serverless, zero management.

• Low, pay-as-you-go cost.

​

Service Model

​

The service consists of one or multiple organizations, or orgs for brevity.  Each org belongs to a customer, and each customer can own one or more orgs.  Each org contains roles and data items.

• A role is a coordination means, similar to a lock, a semaphore, or a lease.  One or more players can play the role concurrently, as configured during the role’s creation.  A player can request to play a role for a certain playtime (usually tens of seconds) and can extend the period by repeating the request before it expires.  After the playtime expires and the player has not requested again, the service removes the player from the role and can grant the role to another player.  When the role is limited to 1 player, it is similar to a mutex (a.k.a, lock).  When the role allows multiple players, it is similar to a semaphore.

• A data item in our service is like a register in a CPU.  It stores a small amount of data (we limit to 100 KB) and is read and written atomically.

​

Within an org, the customer can perform CRUD-like operations on roles and data items.  Those operations are linearizable.  Roles and data items are addressed by paths.  A path is similar to a UNIX file path, such as /my_org/this/is/my_role.role for a role and /my_org/this/is/my_data.data for a data item.  Syntactically, a path may contain any alphanumeric (“a-zA-Z0-9”) and underscore (“_”) characters.  It needs to start with a “/<org>”, followed by zero or more steps separated by forward slash (“/”).  A role’s name needs a “.role”, and a data item’s name needs a “.data” suffix.

Each org maintains an org_time, which is a logical time that ticks every time the org makes a state-change transition, namely rotating the org_key, taking/releasing a role, writing/deleting a data item.  One can think of org_time as the version of the org.  An org_time starts at 0 when the org is created.