Simply superb is the word for this.Very detailed explanation and all stages of system design beautifully covered in the article .Simply love it .Thanks a lot for sharing this .
I think a cache at the client level will also be beneficial, although it comes with the trade-off of maintaining consistency between the different clients.
I agree that a cache at client level would be helpful specially for offline playback (I have added a line there). But, yeah maintaining consistency would be a bit tricky.
Will try to cover this as part of some other problem.
Do we really need centralised service like appservers here? Whats the trade of keeping app service as Facade? Will it not increase the integration complexity with the downstream services and the latency due to addition of a new hop? Why client cant directly integrate with the corresponding microservices and Load balancer can do the redirection based on the application context path? We can avoid this service completely?
I think there is a mistake in section 7.1 about NoSQL databases, you mention "partitioning strategies to distribute data across multiple nodes." What you're describing here is actually sharding - distributing data across multiple servers/nodes.
The key distinction is:
· Partitioning: Splitting data within a single database/server (common in SQL for management)
· Sharding: Distributing data across multiple servers/nodes (common in NoSQL for horizontal scaling)
Really aprreciate the breakdown of Spotify's architecture. The way they handle caching and recomendations with machine learning at scale is pretty impressive from a business perspective. Managing that kind of data volume while keeping latency low must be a masive engineering challenge. Shows why tech infrastructure is such a competitive advantage for them compared to smaller streaming services.
Could've been even better with a code implementation, because after a few scalable systems every system looks exactly the same apart from the initial cost calculations.
Never thought that I would understand the big tech architecture in my 1st read only.
Kudos Ashish 🔥
That’s why I like his commitment
Thanks Ashish
Simply superb is the word for this.Very detailed explanation and all stages of system design beautifully covered in the article .Simply love it .Thanks a lot for sharing this .
I'm so happy to hear this, thank you very much for your kind words!
Best explanation 😁
A very interesting read, I’m loving your system design articles
Great article Ashish, very detailed.
Is it possible to also include the sequence diagrams for communications between Services or Classes within the system? Like a more granular view.
Just a suggestion !
Article is amazing !
Hey, good suggestion.
This article was mostly high-level design.
I think sequence diagram is more low-level, but will try to cover it in a separate article which focuses on low level design.
hey ashish could you create a article for high level design for system like yelp.com or uber or ola,because these are related. and loved this article.
Thanks so much Ashish and looking forward to a low level design article next. Cheers ! Thank you again !
Detailed breakdown, Ashish!
I think a cache at the client level will also be beneficial, although it comes with the trade-off of maintaining consistency between the different clients.
Thoughts?
Thanks Raul!
I agree that a cache at client level would be helpful specially for offline playback (I have added a line there). But, yeah maintaining consistency would be a bit tricky.
Will try to cover this as part of some other problem.
Superb explanation ! Loved it! Your articles have sparked an interest in me to design systems!
Great to hear this, thank you!
Do we really need centralised service like appservers here? Whats the trade of keeping app service as Facade? Will it not increase the integration complexity with the downstream services and the latency due to addition of a new hop? Why client cant directly integrate with the corresponding microservices and Load balancer can do the redirection based on the application context path? We can avoid this service completely?
Hi Ashish,
Could you please help me to understand, I am also having the same question, when i went through the doc!,
I think there is a mistake in section 7.1 about NoSQL databases, you mention "partitioning strategies to distribute data across multiple nodes." What you're describing here is actually sharding - distributing data across multiple servers/nodes.
The key distinction is:
· Partitioning: Splitting data within a single database/server (common in SQL for management)
· Sharding: Distributing data across multiple servers/nodes (common in NoSQL for horizontal scaling)
Where do you create these diagrams? I'm looking for an application to create these diagrams and I can't find any good enough like yours.
Really aprreciate the breakdown of Spotify's architecture. The way they handle caching and recomendations with machine learning at scale is pretty impressive from a business perspective. Managing that kind of data volume while keeping latency low must be a masive engineering challenge. Shows why tech infrastructure is such a competitive advantage for them compared to smaller streaming services.
Thanks
Could've been even better with a code implementation, because after a few scalable systems every system looks exactly the same apart from the initial cost calculations.
Useful
Good article but I am not able to understand the reason of doing such lengthy estimation.
Thank you.