Millions of listeners, petabytes of music, a global ambition, and an architecture that was never designed for it
Before
of data with no clear evolution roadmap
After
requests/second
requests/second
of data managed
of workstreams scoped
A European music streaming leader is preparing to accelerate its international rollout. The service handles 2,000 requests per second in real time on a 3-petabyte data estate: catalogs, metadata, listening histories, recommendations. The architecture, built over the years in a context of rapid growth, had never been considered as a whole with global scalability in mind. The study is sponsored at the highest level and led directly by the CTO.
SITUATION BEFORE
- Operational baseline
- An architecture built over the years in a context of rapid growth: from critical C++ services to legacy PHP services, with tight coupling between services and data models that do not scale to new markets. No overall view geared toward global scalability.
- Teams affected
- The entire platform and the technical teams, but above all the international expansion ambition, stalled for lack of a credible technical roadmap.
- Hidden costs
- An API whose implicit contract holds back any major change. Couplings that would turn into outages at the moment of international expansion, not before.
- Why it was not solved earlier.
- The architecture had been optimized for rapid growth in the European market. The question of global scalability only arose with the international acceleration, and the CTO chose to address it before things broke rather than after.
THE STORY
OUR APPROACH
4 steps to get there
Mapping the pain points
Exhaustive review of practices across the key domains of the information system: performance, availability, data management, integration patterns between services. Formalization of the IT landscape map, collection of volume indicators and identification of bottlenecks, from critical C++ services to legacy PHP services.
Defining the target architecture
Design of the target architecture for the global rollout: AWS solution recommendations, AuroraDB sizing for read-heavy workloads, a Lambda strategy for event-driven processing. Definition of the core principles of API V3 (interface contract, versioning, consumer decoupling).
Technology insights and agility patterns
Introduction of architecture patterns that support agility at scale: event sourcing to trace user actions, CQRS to separate read and write paths on critical volumes, a headless CMS to decouple editorial content production from the technical release cycle.
Prioritizing and scoping the workstreams
Formalization of a structured backlog of 900 person-days of workstreams, prioritized by impact on international scalability, operational risk and short-term feasibility. Findings presented directly to the CTO, with executive sponsorship to commit the teams to the defined roadmap.
THE HARDEST STEP
Assessing 3 PB of data and years of technical build-up in 6 months
The scope was broad: from critical C++ services to legacy PHP services, from AuroraDB databases to Lambda functions, through the NodeJS layers. The point was not to document everything, but to pinpoint exactly what would not hold at global scale.
What we did
Systematic mapping of pain points, a precise and quantified assessment, then construction of a target architecture along three axes (data, processing, content). 900 person-days of workstreams scoped and prioritized to provide a roadmap that gets executed.
What could have failed
An assessment that merely lists problems, without prioritization or a concrete roadmap, would have ended up as a report left to gather dust on a shelf. The point was to produce a roadmap that leadership commits to executing.
RESULTS
The measurable impact
Target architecture defined for the international rollout, API V3 principles formalized, 900 person-days of workstreams scoped and prioritized: a roadmap put into action at leadership level.
Your system holds today. Will it hold tomorrow, at global scale?
Book a discovery callSIMILAR CASE STUDIES
saved on back-office processing
Blank, the Crédit Agricole group neobank for freelancers, was growing fast, but its operations teams were flying blind, held back by a DynamoDB architecture designed for scalability, not for analysis. In 4 months: a real-time pipeline, self-service dashboards, 1 FTE freed up.
Read the case studysaved
Audit, remediation and industrialized data quality for an IT services marketplace used by 150 people, and by thousands of employees through its services, across 3 continents: €2.5M saved through the governance of 15 data repositories.
Read the case study