Important announcement about updates to API V3 and evolving permissions at Eventbrite

If you want to skip straight to the content on the changes that will impact our API developers please visit our Google Group and read the message pinned to the top.

Permissions have been an ever-growing challenge at Eventbrite as we have grown over the years. With scale, permission management has become difficult because of the storage requirements, speed, and latency. Imagine a feature where you need to check the permissions for ten users of an account and 100 of the account’s events. Now take into consideration that each individual event can have multiple permissions associated with it. You can start to get an idea of both the storage requirements and the speed considerations. Even if each permissions check is very fast, executing all of them serially will become slow.

In late 2016 we began working on a Python Library that will change the way we grant users permission to the various entities that exist within Eventbrite. Essentially this library aims to answer the following questions:

• • Can User X take action Y on entity Z

Entity can be event, order, etc.

• • What Users can take action Y on entity Z
  • What entities can User X take action Y on

When the library is invoked it is given parameters which indicate the entities/users are relevant *before* checking permissions. If there are 10 events and 5 users you care about, you load permissions for all these events/users doing a one-time SOA call. Once you have loaded permissions this way, checking permissions is very fast because it’s all in memory. Permissions are inferred in a couple of ways. Inference means that not every single permission is stored in the database.

More general permissions imply more specific ones.

If a User has full permissions on “event” that infers that that user has permissions to do more specific things to that event (change details, add tickets, etc.)  These permissions are not stored, but are inferred.

Permissions on a higher object infer permissions on a lower one:

If a User has full permissions on a “user” that infers that that user has permissions on all the events that are owned by that user.

This allows you to do something like “grant event detail editing” to User Y on User Z. The effect is that User Y can edit the event details for any event owned by user Z.

These can be used powerfully in combination. If you say “grant the event privilege to User Y on User Z” it means that User Y can now do anything to any event owned by User Z.

Inference greatly simplifies operations such as changing the role of a user or bulk deleting events. If we were to store each permission separately, we could potentially need to update thousands of rows in the database to accomplish this one task.

Most recently the permissions library was used as one part of an update we are making to our product offering. Starting this fall, this update will allow organizers to choose between three tailored product packages to best achieve their goals. You can learn more about the new Eventbrite packages here.The rollout will affect our API developers. If you are an API developer please visit our Google Group for detailed information on how your apps will be impacted and how you can prepare.

Photo by Christian Wiediger on Unsplash