The success and popularity of Spotify have stunned everyone - right from the music and entertainment industry to the technology and business world.
Spotify was launched to counter the rising menace of music piracy. It was estimated that 30-40% of revenues generated by the music industry were lost due to piracy, and artists who created original music failed to get fairly compensated for their art.
Understanding these problems, Daniel Ek and Martin Lorentzon from Sweden launched Spotify in 2006 and instantly became the world’s most popular music streaming service. With more than 422 million active users and 182 million paid users, Spotify has topped the charts of the music streaming industry and is right now one of the most preferred and popular platforms for accessing all kinds of music, easily and seamlessly.
Spotify is available across 182 nations, hosts 82 million+ songs, and is available to users in both free and freemium mode, with revenues generated from advertisements, and paid subscriptions.
Spotify has an interesting revenue model, which is unlike the traditional music industry, where the artists are paid based on every song sold. With Spotify, record labels who own the rights to the music are paid upto 70% royalty of the revenues generated, and the artists get paid from these record labels directly.
In this blog, we will discuss the software architecture behind Spotify, and understand how they are able to support billions of music streams, concurrently for millions of users.
Decoding Software Architecture Of Spotify
Software architecture is the blueprint and the roadmap, based on which the entire software is created, and every mobile/digital platform needs a software architecture to start with. There are basically two types of software architecture that companies usually rely on: Monolithic Architecture and Microservices.
Spotify is based entirely on Microservices architecture, which has been confirmed and explained by Kevin Goldsmith, who was the former CTO at Spotify. API for User Personalization Why Microservices Architecture At Spotify?
The software architecture of Spotify is heavily dependent on services, and this is the reason microservices-based architecture was finalized for Spotify, and it worked. The backend of Spotify needs hundreds of services, most of them tiny and simple, but they need to be served in run-time, without any delay.
In order to serve these hundreds of services, Spotify's technical team deployed a microservices-based architecture, wherein it serves to address one single service-need at a time: Be it song retrieval, sharing recommendations, searching, or simply user verification (for free and paid model).
How Do Services Work & Respond?
Services are usually written in Python and/or Java language, with few exceptions. And they communicate with one another via Hermes protocol, which Spotify has developed from scratch using ZeroMQ and Protobuf.
However, some older services created in the beginning still use HTTP and XML/JSON for communication.
For database and storage-based services, PostgreSQL & Cassandra are used by Spotify. Cassandra is preferred for content-based services such as searching the songs or retrieving metadata of the songs, in run-time.
There exists a highly specialized backend service called ‘accesspoint’, which is constantly in touch with various clients, for swift and precise communication. The protocol which enabled seamless communication between the clients and the ‘accesspoint’ has also been built by Spotify engineers, and hasn’t been made public.
Software infrastructure within Spotify is heavily dependent on Debian, while open-source software is preferred for various activities.
Cross-Site Communication The Secret Of Swift Music Streaming On Spotify
Now, we have an overview of how services work and respond, and we have shared why Microservices-based software architecture has been deployed at Spotify.
Now, here is a secret about why Spotify is able to swiftly retrieve songs for the end-users, and why music streaming is so fast, and reliable.
Within the Microservices based architecture, there are hundreds of software developers working concurrently, who are managing different types of services and their communication.
Now, the secret is that each of these software developers is working in a closed territory, with specific functionalities and missions. Every microservice has just one responsibility and objective, and a majority of such microservices have their own private database with their own logic, and they cannot be intervened by other databases of other microservices. This is the reason Spotify is so fast, and precise, and fulfills the end-user's needs so promptly. Once a request has been placed for any specific task, the application responds swiftly, deploying different services across different machines, and having personalized and customized performance parameters, depending on the specific service being called. Spotify Backend Model Seamless Change Management Of Logic
Now, what if the software developer needs to change the logic of any feature? There isn’t any issue of time lag or disruption of the entire application, because each microservice has its own logic, and implementing changes is very easy.
The specific service which is connected with the feature needs to be worked upon, the edits are made, and then only that service is tested, and then instantly deployed. Hence, that service is now changed, logic altered, and the feature will now have new functionality. This service will start communicating with the application once the deployment is done, and there is absolutely no need for the entire application to be re-tested, and re-deployed.
This change management feature of microservices being used as the software architecture of Spotify is one of the strongest and most powerful capabilities, which makes Spotify fast and user-friendly.
Interestingly, the software architecture of Spotify has been developed in a way that all the possible clients of the application: mobile, desktop/laptops, and libspotify (Spotify’s embeddable library), all share a common codebase.
Using this common code-base, the developers can modify or enhance the client functionality and offer a unique user interface for the end users.
Since this common code-base is written in C++ language, changes and edits in the main user interface are also easy and seamless. The specific platform adoptions are written in platform-specific languages, for example, ObjC for iOS.
If you are looking for audio streaming app development, then our team at TechAhead can help you right away. Based on your specific requirements, we can deploy Spotify-inspired software architecture for your mobile app, loaded with powerful and scalable features. Schedule an appointment with our Mobile App engineers right here.
Comments