Moving from a Monolith to Microservices at SoundCloud

| by Jan Stenberg Follow 34 Followers on Jun 29, 2014. Estimated reading time: 1 minute |

Moving SoundCloud into a microservices architecture has been crucial in enabling our teams to build new features faster, Phil Calçado writes in a three-part series sharing their experiences moving away from a monolithic system.

SoundCloud, an online audio distribution platform where Phil is Director of Engineering, was created as a single Ruby on Rails application, but over time patching the system instead of resolving the scalability problem made them decide to fundamentally change their way of building products. The first step was the architecture and a decision to move to a microservices architecture. Due to earlier bad experiences of big-bang refactoring they went for an approach of not adding anything new to the old system, instead building new features as microservices.

A problem that soon arose was that due to so much of the logic remaining in the old system, most of the new services still had to communicate with it. A solution for this was to use the public API together with a new internal API, which also helped them keep all new microservices decoupled from the old system.

After the architectural changes were made, the next challenge was extracting features from the old application. The concept of bounded context from Domain-Driven Design (DDD) was chosen to define well-contained feature sets. Avoiding big-bang refactorings required that for each feature set extracted, the new microservice needed to work with the old system for as long as it took to completely move the logic. During the transition the new service was accessing the old database which meant that only the read-path could be implemented until the service was fully functional. By applying these principles the teams have been able to extract most existing features from the old system moving them into microservices.

Based on their own preferences they decided to stay with the JVM platform and the different languages available. When looking into frameworks to meet their requirements for RPC, resilience, and concurrency they settled on using Finagle, a protocol-agnostic RPC system, after investing time to address some minor issues.

Based on experiences of their work, Phil summarises by stating that the new microservice architecture has proven itself crucial for developing production-ready features with much shorter feedback cycles.

Phil’s ambition is to complete his series by describing how they are using Finagle and Scala to move from a single RESTful API to optimized back-ends.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you