Arpit's Newsletter read by 90000+ engineers
Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.
Building a central, robust, extensible and highly available authorization service is no joke
and @Airbnb does it beautifully
here’s a thread about its architecture and key design decisions… 🧵👇
It is all about managing fine-grained control over different entities, for example:
why do we need a service for this?
If each microservice handles its own authorization, then there would be
hence, it is beneficial to create a central auth service. Let’s see how it is modeled.
can user A edit comment C?
A - is the principal, C - is the entity, and edit - is the relation
The tuple is represented and (optionally stored) in the database as
<entity> # <relation> @ <principal>
if user A has owner privileges on comment C, it will be represented (and optionally stored) as
C # OWNER @ A
Storing one entry for each entity and relation will make the data explode, For example:
if A owns a comment C, then he/she can read and write to it as well. This would make us have 3 entries in the database
C # READ @ A
C # WRITE @ A
C # OWNER @ A
hence…
we need a way to define relations between relations and entities to reduce the size of the data.
A simple YAML-based config would look like this
LISTING:
# WRITE:
union:
- # WRITE
- # OWNER
# READ:
union:
- # READ
- # WRITE
The above configuration implies,
Anyone with the write and owner relation can write and anyone with read and write (and transitively owner) relations can read the listing on Airbnb.
To check if user A can read listing L, we hit
check (listing:L, READ, user:A)
It evaluates as
because of union
, if anyone of these exists in DB, check
evaluates to True.
Himeji (authorization) service is consist of 3 layers
Let’s take a detailed look at each in detail.
The data layer of the Himeji service consists of
The caching layer of the Himeji service is super-critical for performance as it ensures low response time at scale.
The orchestration layer is used by clients and internal jobs to interact with the service. The layer
This design is taken from @Airbnb’s Engineering Blog and it is linked in the description of the video attached.
Here's the video ⤵
Alongside my daily work, I also teach some highly practical courses, with a no-fluff no-nonsense approach, that are designed to spark engineering curiosity and help you ace your career.
A no-fluff masterclass that helps experienced engineers form the right intuition to design and implement highly scalable, fault-tolerant, extensible, and available systems.
An in-depth and self-paced course for absolute beginners to become great at designing and implementing scalable, available, and extensible systems.
A self-paced and hands-on course covering Redis internals - data structures, algorithms, and some core features by re-implementing them in Go.
Arpit's Newsletter read by 90000+ engineers
Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.