Why Sovereign

From Netflix to a Startup SaaS, the move is the same.

Enterprise, mid-market, and small platforms are all landing on the same architecture — sovereign modules with clean data ownership, built incrementally alongside the live system. Different scales, different starting points, one direction of travel.

Enterprise

Enterprise

Five companies that publicly documented the transition — what broke, what they built, and what changed after.

  1. Netflix01

    The three-day outage that changed everything

    What happened
    August 2008 database corruption took Netflix down for three days. By 2016 the company had finished a seven-year migration from an Oracle-backed Java monolith to more than a thousand independent microservices on the cloud — each small enough for a team of two to eight engineers to own end-to-end, including its own data store.
    The lesson
    A monolith doesn’t warn you that it’s fragile until it’s catastrophically fragile. Independent modules with isolated data stores aren’t just faster to deploy — they’re how you bound the damage when something, inevitably, goes wrong.
  2. Shopify02

    The modular monolith nobody talks about

    What happened
    In 2017 Shopify surveyed engineers on what was slowing them down inside a large Ruby on Rails monolith. Instead of moving to microservices, they built a modular monolith — one codebase, strict domain boundaries enforced by tooling, each component with a defined public API and its own data. Componentization let engineering scale past $75B in annual GMV without collapsing under coordination overhead.
    The lesson
    Microservices are one way to enforce boundaries. A well-designed modular monolith is another. The goal — sovereign modules with clean interfaces and data ownership — can be achieved without distributing your system across a network.
  3. Airbnb03

    When the monolith slows the team

    What happened
    Airbnb’s Ruby on Rails monolith stopped being a technical problem and became an organizational one — build times stretching into many minutes, test suites too slow to run locally, deployments requiring coordination across teams inside the same codebase. Migration to a service-oriented architecture with more than 1,000 services and an API gateway compressed build and deploy times sharply and let each team ship on its own schedule.
    The lesson
    A monolith slows your team before it slows your system. If the architecture is making it harder to hire, onboard, and move independently, the real cost is already compounding — even if the site is up.
  4. Uber04

    When the architecture is right but the operations aren’t

    What happened
    By 2019 Uber ran 4,500 microservices, 4,000 engineers, and more than 100,000 deployments per week. The seams weren’t in the services — they were in the humans deciding where each service ran, how it rolled out, how traffic shifted. UP, Uber’s centralized deployment platform, automated placement, zone management, and rollouts, migrated two million compute cores by 2022, and returned tens of millions of dollars and tens of thousands of engineering hours per year.
    The lesson
    Modular architecture doesn’t end at design. The operational model — how services are placed, deployed, and managed — has to scale alongside the architecture. Without it, complexity migrates from the codebase to the humans managing it.
  5. Amazon Prime Video05

    The case for right-sizing

    What happened
    In March 2023 Prime Video moved its video-quality monitoring system from AWS Step Functions microservices back to a single-process design and cut costs 90%. The distributed design was billing per state transition and shipping large video frames between services over the network — architecture the problem domain never actually required. The broader Prime Video system stayed distributed; this one subsystem was a different kind of problem.
    The lesson
    Modular thinking means right-sizing your boundaries to the actual problem domain. Distributed systems are powerful and expensive; the decision to distribute should come from the problem, not from the pattern.
    Source
    InfoQ — Amazon Prime Video: Microservices to Monolith Cut Costs 90% →The original Prime Video Tech blog post has since been taken down; InfoQ preserves the primary quotes from Marcin Kolny and the 90% figure with context.

Mid-Market

Mid-Market

Five mid-market platforms that modernized without stopping — phased migrations, incremental cutovers, live customers throughout.

  1. Sievo06

    Nine years is not a failure

    What happened
    Sievo, a Finnish procurement analytics company, has been migrating a monolithic application from a private Finnish data center to a cloud-native microservice platform since 2016. Services are extracted from the monolith and go live in production one at a time — each owning its own data store and lifecycle — while the rest of the platform keeps running and 170+ enterprise clients keep transacting.
    The lesson
    Transformation is not a project with a deadline — it’s a series of committed decisions over time. The companies that succeed start before the pain is unbearable and accept that running the business and improving the architecture happen simultaneously.
  2. Appsmith07

    Arriving at the right answer from first principles

    What happened
    Appsmith’s customers install its internal-tools platform on their own infrastructure — often air-gapped, often without deep Kubernetes expertise. When the engineering team hit the usual scaling pains inside a maturing monolith in 2021, microservices were the default answer. They chose a modular monolith instead: one deployable JAR, clean module boundaries, enforced interfaces, explicit data ownership. Deployment friction dropped and customer acquisition improved.
    The lesson
    Architecture decisions have to start with deployment reality, not industry fashion. A microservices pattern that creates unacceptable operational complexity for your customers is not a solution — it’s a different problem with a different victim.
  3. A leasing platform08

    The coordination tax

    What happened
    A paperless leasing platform expanding across regional markets was paying weeks of cross-team coordination for every new market — universal platform logic and market-specific rules were woven into the same codebase. Decomposing the platform into modular Java services with clearly owned domains, CI/CD, Kubernetes, and a standalone localization module cut new-market launches from months to weeks, tripled release cycles, and improved platform performance under load by 35%.
    The lesson
    The cost of a monolith often appears not as downtime but as coordination overhead — a tax every new initiative pays at the point of expansion. Clean module boundaries eliminate most of that tax before it accumulates.
  4. A U.S. SaaS company09

    Eight weeks, no downtime

    What happened
    A U.S. SaaS platform running with fragile deployments and tightly coupled code — where touching one area reliably surfaced problems somewhere apparently unrelated — could not stop for a full rewrite. A phased migration prioritized the most critical and most fragile domains first, modernized them while the platform kept running, and retired legacy code as each replacement was validated in production. Core migration completed in eight weeks with zero customer-facing downtime, a 60% reduction in engineering effort on feature delivery, and 124% documented ROI.
    The lesson
    “We can’t stop” is a real constraint, not an architecture sentence. A phased, domain-by-domain migration keeps the business running while systematically eliminating the coupling that made the platform fragile — and the ROI tends to be immediate.
  5. A U.S. sales intelligence platform10

    AI needs a clean data layer first

    What happened
    A U.S. sales intelligence platform wanted to add predictive scoring, behavioral pattern detection, and recommendations — capabilities the existing monolith could not support because data lived inside application logic and tables were named after code concepts, not business entities. A multi-year, domain-by-domain decomposition treated the data layer as the first and most critical milestone. Analytics ran three times faster after the migration, stability climbed above 90%, and the AI features that had been impossible in the monolith became the product’s primary differentiator.
    The lesson
    AI capabilities cannot be bolted onto entangled data. Before a machine-learning layer can function reliably, the data it needs has to be sovereign — clean, bounded, and separated from business logic. Modular architecture is an AI-readiness problem as much as a deployment one.

Additional

Additional case studies

Five more documented transitions — an organizational reframing, a healthcare data platform, a cloud-native rebuild, an enterprise transformation, and a deliberate case against microservices.

  1. Spotify11

    When your architecture decides your org chart

    What happened
    Spotify’s microservices migration is usually framed as a scaling story. The more interesting part is what it did to the organization: playlist management, personalized recommendations, and audio streaming each became their own service, and that made the squad model possible — small autonomous teams with end-to-end ownership of a single domain. Sovereignty at the code level created sovereignty at the team level.
    The lesson
    Organizational agility has a prerequisite — technical modularity. You can name teams whatever you want, but if the services are coupled, the teams will be too.
  2. Innovaccer12

    The hidden cost of infrastructure in healthcare data

    What happened
    Innovaccer runs a health data platform that unifies patient records from EMRs, claims systems, labs, and connected devices — one of the harder data problems in enterprise software. Migrating to a cloud-native SaaS model on AWS reduced infrastructure management effort by 65%. The engineering time that had been going to servers, patching, and operations moved to unification logic, care-gap detection, and analytics — the features that actually make the platform useful.
    The lesson
    Reducing infrastructure overhead in complex domains like healthcare isn’t an IT optimization — it’s a product strategy. Engineering time is finite; what it’s spent on determines what gets built.
  3. Cloudera13

    Why the sidecar model outperforms the handoff

    What happened
    Cloudera moved from Hadoop-era infrastructure to cloud-native architecture through AWS’s Migration Acceleration Program — but the distinguishing feature wasn’t the tooling. AWS embedded technical experts directly alongside Cloudera’s own engineers, identifying automation opportunities together, catching scalability issues as they emerged, and building capability that stayed with the team after the program ended. Jim Gath, Director of Cloud Operations: “our builds are 40% faster and far more reliable.”
    The lesson
    Transformation that involves operational complexity needs experts embedded in the work, not advising from outside it. The 40% build improvement came from people working side by side, not from a document.
  4. A Big 4 firm14

    The cobbler’s shoes problem, at enterprise scale

    What happened
    One of the world’s largest consulting firms — an organization that advises clients on digital transformation for a living — was running its own operations on a tightly coupled on-premises monolith. Migration to microservices on AWS EKS, with API gateway, Kafka for async communication, and full CI/CD on CodeBuild and CodePipeline, cut development and maintenance costs 30%, shortened release cycles, and delivered genuine fault isolation.
    The lesson
    Legacy architecture is almost never a sign of poor engineering judgment at the start — it’s a sign the business succeeded. The question is how quickly you recognize when the original design can no longer carry the load.
  5. Gusto15

    The pragmatic case against microservices

    What happened
    When Gusto needed to add Time Tracking to its payroll platform, the obvious answer was a new microservice. Engineer Alicia Tran laid out why they didn’t: several synchronous touchpoints with the core monolith (authentication, payroll sync, manager approval) were manageable in-process and would have become failure points across a network. Instead they built a Rails engine — same repository, same database, explicit API boundary, serialized message-passing — and later described the broader unbundling as “chipping away,” with packwerk enforcing module boundaries.
    The lesson
    Modularity is the goal; microservices are one implementation. A well-bounded module inside a monolith can provide most of the organizational benefits of a separate service, at a fraction of the operational cost.
Read the sovereign methodology →See the Sovereign Pre-Builts →