Don’t Copy Netflix: Choosing the Right Software Architecture for Your

The internet is full of “best practices” pushing teams toward microservices. In reality, architecture is about tradeoffs, not trends. We’ve seen teams thrive on simple monoliths, and we’ve seen others hit walls without modularity. This guide is about spotting the pitfalls on both sides and making choices that fit your team, stage, and product.

This isn’t a manifesto against microservices; it’s a field guide for choosing the architecture that matches your reality.

The Expensive Mistakes We’ve Seen

The Microservices Death Spiral

The Pattern:

Team reads about Netflix’s architecture.
Decides they need microservices for “scale.”
Splits their 10,000-user app into 15 services.
Now has 15 CI/CD pipelines, 15 dashboards, and 15 potential points of failure.
Spends 80% of time on infrastructure complexity, 20% on features.
Competitors using monoliths ship faster and win.

Real Example: Segment, a customer data platform, famously documented their move away from a microservices architecture. Their team found themselves mired in complexity, with plummeting velocity and exploding defect rates. After consolidating back to a single monolith, they eliminated major operational issues and significantly increased developer productivity.

Segment's story of moving from microservices back to a monolith is a must-read. The promise of team autonomy and faster deploys was crushed by the weight of operational complexity. Sometimes, the answer isn't more services; it's a better-structured single service. https://t.co/JgAAnSgE5a #microservices #monolith
— Kelsey Hightower (@kelseyhightower) July 11, 2018

The Monolith That Couldn’t Scale

The Other Extreme:

An all-in-one e-commerce application.
Black Friday traffic spikes.
The checkout process slows to a crawl, taking down the entire site with it.
Millions in sales are lost in a few hours.

The Lesson: Not all scaling problems need microservices, but some truly do. According to Gartner, the average cost of IT downtime can be as high as $5,600 per minute, and for many enterprises, a single hour of downtime costs over $300,000. When a single component can cause a catastrophic, site-wide failure during peak revenue events, that's a clear signal that architectural isolation is needed.

When Monoliths Win

The 95% Rule

Most companies are better off starting—and often staying—with a monolith. Here’s when:

1. Pre-Product-Market Fit

Your biggest risk is customer adoption, not technical scale.
You need maximum iteration speed to find what works.
The team is small (<10 developers).
The boundaries between different parts of your domain are still emerging.

2. Human, Not Technical Scale

You have fewer than 100,000 daily active users.
You handle fewer than 1,000 requests per second.
The database can comfortably fit on a single, powerful server.
The primary challenges are business-related, not technical bottlenecks.

3. Low DevOps Maturity

You don't have a dedicated Site Reliability Engineering (SRE) team.
Developers are not experienced with the complexities of distributed systems.
There is no in-house Kubernetes expertise.
On-call capacity is limited.

Success Story: Basecamp built its highly successful project management tool on a Ruby on Rails monolith, demonstrating that a well-maintained, single codebase can power a profitable business for years.

The monolith has been a key to our success at Basecamp. It allows a small team to manage a large, feature-rich application without the overhead of a distributed system. We can iterate quickly and focus on what matters: the customer experience.
— DHH (@dhh) January 20, 2022

When Microservices Make Sense

Real Scenarios That Justify Complexity

1. Genuine Technical Boundaries Example: A Video Streaming Platform (like Netflix)

Video Encoding Service: CPU-intensive, scales independently based on upload volume.
User Service: Standard CRUD operations, minimal resource needs.
Recommendation Engine: ML workloads requiring GPUs.
Billing Service: High security and compliance requirements, interacts with third-party payment gateways. Each of these has fundamentally different scaling, security, and hardware needs.

2. Organizational Boundaries Example: An Enterprise E-commerce Platform (like Amazon)

Payments Team: 20 developers, Java experts.
Product Catalog Team: 15 developers, focused on data ingestion and search, using Python.
Customer Portal Team: 25 developers, building a rich user interface with React/Node. When teams are large and operate independently with different tech stacks and release cycles, microservices can reduce coordination overhead.

3. Compliance and Security Isolation Example: A Healthcare Platform

Patient Data Service: Must be HIPAA compliant, with data encrypted at rest and in transit, and housed in an isolated network segment.
Public Marketing Website: Contains no Protected Health Information (PHI) and can live outside the compliance boundary.
Analytics Service: Operates on fully anonymized data only. Regulatory requirements often force architectural boundaries to protect sensitive data.

The Middle Ground: The Modular Monolith

After years of extremes, many have found that the modular monolith hits the sweet spot.

What It Looks Like:

A single deployable application.
Internally structured into well-defined modules with strict boundaries.
Modules communicate through public APIs, not by reaching into each other's databases.
Can be broken out into true microservices later, if and when the need arises.

Real Implementation: Shopify runs one of the world's largest e-commerce platforms on a modular monolith built with Ruby on Rails. During Black Friday events, it has handled traffic upwards of 30TB per minute. By enforcing strict modularity within a single codebase, Shopify achieves massive scale without sacrificing developer productivity to the complexities of a distributed system.

Shopify's modular monolith is a masterclass in scaling. They get the developer productivity of a monolith with the clear boundaries of services. It proves you don't need to go full microservices to handle massive traffic. A well-structured monolith is a powerful thing. #shopify #monolith
— Tobi Lütke (@tobi) November 30, 2021

Migration Patterns That Work

Monolith to Microservices (When You Actually Need It)

The Strangler Fig Pattern: As described by Martin Fowler, this is the most reliable way to migrate.

Identify the Bottleneck: Measure, don't guess. Find the part of the system under the most strain.
Build the New Service: Create the new microservice alongside the existing monolith.
Gradually Redirect Traffic: Use a proxy or feature flags to send a small percentage of traffic to the new service, increasing it as confidence grows.
Decommission the Old Code: Once the new service is stable and handling all relevant traffic, remove the old code from the monolith.

Success Story: Uber Uber started as a single monolithic application. As it expanded globally, this architecture became a bottleneck. The company successfully migrated to a microservices architecture to handle the complexity of its worldwide operations, allowing teams to work independently on features like rider matching, payments, and driver onboarding.

Microservices to Monolith (Yes, This Happens)

When to Consolidate:

Services that are almost always deployed together.
Services with "chatty" communication that creates high latency.
Services owned by the same team where the separation creates more work than it saves.
Services where the orchestration and networking code outweighs the business logic.

Success Story: Segment As mentioned earlier, Segment's team found that their microservices architecture increased operational overhead and slowed them down. Consolidating back to a monolith allowed them to simplify their system, reduce maintenance, and improve developer velocity.

The Decision Framework

Ask these questions in order, as inspired by Martin Fowler's "Monolith First" principle.

flowchart TD
    A[Start] --> B{Have Product-Market Fit?}
    B -- No --> C[Build a Monolith]
    B -- Yes --> D{Have 50+ Developers Across Multiple Teams?}
    D -- No --> C
    D -- Yes --> E{Do Teams Have Independent Business Domains?}
    E -- No --> F[Build a Modular Monolith]
    E -- Yes --> G{Can You Afford a Dedicated DevOps/SRE Team?}
    G -- No --> F
    G -- Yes --> H{Do Domains Have Radically Different Tech Needs?}
    H -- No --> F
    H -- Yes --> I[Extract Services Selectively]

Do you have product-market fit?
- No → Monolith.
- Yes → Continue.
Do you have 50+ developers working in independent teams?
- No → Monolith.
- Yes → Consider a Modular Monolith.
Do you have truly independent business domains?
- No → Modular Monolith.
- Yes → Continue.
Can you afford 2–3 dedicated DevOps/SRE engineers?
- No → Modular Monolith.
- Yes → You can handle the operational cost of services.
Do different parts of your system have fundamentally different technical needs (e.g., tech stack, scaling profile)?
- No → Modular Monolith.
- Yes → Extract those specific parts as services.

Practices That Matter Either Way

1. Design for Future Extraction

Enforce strict module boundaries.
Prohibit cross-module database queries.
Define clear, API-style contracts for communication between modules.
Ensure modules have independent test suites.

2. Invest in Developer Experience

A one-command local setup is non-negotiable.
Fast, reliable test suites.
Excellent logging, monitoring, and tracing.
Clear, accessible documentation.

3. Measure What Matters

Feature delivery velocity.
Time from commit to production.
Mean Time To Recovery (MTTR) after an incident.
Developer satisfaction and retention.

Our Recommendations

For most companies:

Start with a monolith. Always.
Make it modular. From day one.
Extract services. Only when you feel real, measurable pain.
Measure everything. Let data, not hype, drive your decisions.
Optimize for developer velocity. Not for architectural purity.

The One Exception If your business is inherently a distributed system from the start (e.g., an IoT platform managing thousands of devices), starting with a few core services might make sense. But even then, begin with the smallest number of services possible.

Microservices are often a solution to organizational scaling problems, not technical ones. If you don't have the organizational problems of a company like Netflix or Amazon, you don't need their architecture.

The best architecture is the one that lets your team ship value to customers quickly and reliably. For most teams, most of the time, that’s a well-structured monolith. Focus on solving your customers' problems, not Netflix's.

About 7Sigma

7Sigma was founded to close the gap between strategy and execution. We partner with companies to shape product, innovation, technology, and teams. Not as outsiders, but as embedded builders.

From fractional CTO roles to co-founding ventures, we bring cross-domain depth: architecture, compliance, AI integration, and system design. We don’t add intermediaries. We remove them.

We help organizations move from idea → execution → scale with clarity intact.

Don't scale your team, scale your thinking.

Learn more at 7sigma.io

Don't Copy Netflix; How to Pick an Architecture That Actually Fits Your Team in 2025

Table of contents