When SoundCloud, which is the leading music streaming service in the US, made the shift from mono to micro, it allowed their teams to dramatically increase their release velocity. However, they learned quickly that if a service's API were to be changed in a way that broke existing code, it may cause a chain reaction of failures.

To mitigate this risk, SoundCloud implemented consumer-driven contract tests. With these tests, consumers could define their interactions and expectations with provider services, and providers verified these contracts every time the service was built.

<aside> 💡 With over 300 services in place, SoundCloud took advantage of PACT-based contract testing to avoid breakage and maintain a stable and reliable system.

</aside>

Final _PH - eBook 01 (11).png

This is a true story of product problems at Soundcloud 👇

Soundcloud, started a year after Spotify, was the most premier music streaming service

But early 2016, things started becoming painfully slow for Soundcloud

Adding new features became harder & harder. The product team was frustrated. Engineering did not know how to fix their delivery speed

What led to these troubles 👇

Soundcloud engineering team had grown to 50+ that handled 300+ micro-services but they were still testing their app like a monolith.

✳️ Lots of end to end tests that were slow and flaky, not to mention a maintenance nightmare 🚫

✳️ Lots of manual QA that was slow and very expensive even for the scale Soundlocud (raised 500M+) 🐌

A post mortem was ordered on why was their testing strategy not working. The diagnosis was simple:

[1] 80% of these tests reported outages for reasons other than actual functional errors or the underlying code 🤦‍♂️

[2] Not to mention, #1 reason for slowing down releases 😡

Soundcloud junked this approach 👋

Moved to a new testing strategy that was faster, more suited for their micro-services first set-up.