How Netflix API evolved through 4 stages
From Netflix TechBlog (2020) & a LinkedIn post -
Netflix is known for its loosely coupled and highly scalable microservice architecture. Rather than exposing 100s of microservices to UI developers, Netflix offers a unified API aggregation layer at the edge. Netflix's Studio Ecosystem architecture has evolved in distinct phases, all motivated by reducing the time between idea and implementation, improving the developer experience, and streamlining operations. The architectural phases look like:
๐ญ. ๐ ๐ผ๐ป๐ผ๐น๐ถ๐๐ต
Like everyone else, Netflix started with a monolithic architecture where the entire application was packaged and deployed as a single entity.
๐ฎ. ๐๐ถ๐ฟ๐ฒ๐ฐ๐ ๐๐ฐ๐ฐ๐ฒ๐๐
To improve team autonomy and speed, the monolith was split into microservices. Each client made direct requests to the microservices. But with hundreds of them, exposing everything wasn't ideal.
๐ฏ. ๐๐ฎ๐๐ฒ๐๐ฎ๐ ๐๐ด๐ด๐ฟ๐ฒ๐ด๐ฎ๐๐ถ๐ผ๐ป ๐๐ฎ๐๐ฒ๐ฟ
They built an API Gateway to bind all the services together and presented a unified front to the clients.
The API Gateway was supposed to bring order, but instead it became the new monolith as team grew and services multiplied.
๐ฐ. ๐๐ฒ๐ฑ๐ฒ๐ฟ๐ฎ๐๐ฒ๐ฑ ๐๐ฎ๐๐ฒ๐๐ฎ๐
They built a federated GraphQL gateway to dismantle the API gateway monolith. The federated gateway eliminated complicated business logic, now routing queries directly to responsible services and stitching responses together.
Comments
Post a Comment