Arpit's Newsletter read by 38000+ 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 ⤵
Super practical courses, with a no-nonsense approach, are designed to spark engineering curiosity and help you ace your career.
An in-depth, self-paced, and on-demand course that for early engineers to become great at designing scalable, available, and extensible systems at scale.
A masterclass that helps experienced engineers become great at designing scalable, fault-tolerant, and highly available systems.
A course that helps covers Redis internals by reimplementing its core features like - event loop, serialization protocol, pipelining, eviction, and transactions.
Arpit's Newsletter read by 38000+ engineers
Weekly essays on real-world system design, distributed systems, or a deep dive into some super-clever algorithm.