System architecture 1

System architecture is never one-size-fits-all. It adapts, evolves, and accumulates debt as companies grow. Whether you’re launching with a monolith, embracing microservices, or re-architecting from the ground up, each choice carries trade-offs. This article explores how companies across fintech, e-commerce, SaaS, gaming, and logistics encountered, managed, and mitigated architectural debt. Through these real-world stories, you'll gain insight into the system architecture strategies that enable long-term scalability and sustainability.

Fintech: Microservices from Day One – Strategic or Premature?

In 2015, Monzo launched its digital bank with a bold system architecture decision: adopting a microservices-first approach from day one. Their rationale was pragmatic - 24/7 banking services demand high availability, fault isolation, and operational flexibility from the beginning.

This decision aligned with non-functional requirements like scalability, resilience, and deployability. However, by 2024, Monzo’s architecture comprised over 2,800 microservices, surfacing an entirely new class of debt. 

 

Architectural Pain Points:

  • Excessive service fragmentation, leading to inter-service orchestration overhead
  • Version drift across services with inconsistent dependency management
  • High cognitive load for cross-cutting updates, e.g., security patches or shared concerns

 

Architectural Remediation:

  • Creation of a migration team to centralize repetitive platform updates
  • Internal development of mass-refactor tooling to support bulk edits and testing
  • Shift to a monorepo strategy to unify configuration and deployment processes

 

A well-justified microservice architecture can become a liability without strong platform support, dependency governance, and systemic refactoring mechanisms. 

System_architecture_ASSIST_Software_2

E-Commerce: Breaking the Monolith to Enable Agility

Amazon: SOA Before It Was Cool

Amazon’s early-2000 system architecture evolution began as they faced classic monolithic bottlenecks, tightly coupled components, shared state, and synchronized deployments.

 

Core Constraints:

  • Limited parallelism in development
  • Single point of failure at the database layer
  • Coupled deployment lifecycle, restricting release velocity

 

Their Transition:

  • Authored the Distributed Computing Manifesto
  • Adopted Service-Oriented Architecture (SOA)
  • Organized teams as two-pizza units, aligning Conway’s Law to service ownership

This facilitated bounded contexts, autonomous deployments, and domain-driven interfaces, setting the standard for large-scale SOA.

 

Zalando: Autonomy with Governance

Facing challenges in their monolithic system architecture, Zalando transitioned to microservices supported by engineering-wide alignment documents like their “Rules of Play.”

 

Applied Practices:

  • Enforced contract-first development and backward compatibility
  • Introduced a no shared libraries policy to decouple services
  • Adopted API versioning and documentation standards

 

Their success hinged on combining technical autonomy with organization-wide architectural conventions.

 

SaaS: Microservices vs. Modularity Trade-Off

Segment: Microservices for a Small Team

Segment’s system architecture was decomposed too early, creating more overhead than benefit. Their story highlights an architectural anti-pattern: the distributed monolith, where service boundaries exist in code but not in practice.

 

Challenges Faced:

  • Overhead in service-to-service reliability and integration testing
  • Redundant functionality and data duplication
  • Operational burden disproportionate to team size

Their course correction involved consolidating services into a modular monolith written in Go, restoring control, and improving reliability.

 

Khan Academy: Strategic Rewrite via Strangler Fig

With Python 2 deprecated, Khan Academy embarked on a system architecture rewrite using the Strangler Fig pattern:

  

  • Incrementally replaced monolith functionality
  • Built services in Go with clearly defined responsibilities
  • Froze legacy systems during migration to avoid regression

 

Their careful handling of architecture debt ensured continuity of service while improving long-term sustainability. 

System_architecture_ASSIST_Software_3

Gaming: Scaling Infrastructure to Match Global Load

Pixel Federation: Scaling Beyond the Legacy Stack

As user volume surged, Pixel Federation’s legacy system architecture revealed critical limitations:

  • Lack of elasticity under load  
  • Latency due to single-region deployment
  • Operational complexity from vertical scaling

 

Modernization Strategy:

  • Re-architected using microservices deployed on Kubernetes
  • Leveraged AWS services (e.g., DynamoDB, S3) for scalable persistence
  • Introduced multi-region deployment to reduce latency for global users

 

Riot Games: Platformization to Mitigate Service Sprawl

Riot Games invested in platform teams to proactively manage growing system architecture complexity and microservice sprawl.

 

Their approach included:

  • Creation of DevX (Developer Experience) paved the path to bootstrap services with preconfigured infrastructure
  • Adoption of service mesh (Istio) for consistent traffic policy and observability  
  • Standardization of telemetry, logging, and CI/CD practices

 

This minimized divergence and enabled scaling without compounding technical complexity. 

System_architecture_ASSIST_Software_4

Transportation & Delivery: Navigating Hypergrowth Architectures

Uber: From Monolith to Unbounded Mesh

Uber’s early system architecture began as a monolithic Python app, but rapidly evolved into a sprawling mesh of microservices.

 

This shift led to:  

  • Cascading failures due to weak fault boundaries  
  • Obscure service ownership and responsibility  
  • Prohibitive onboarding due to system complexity

 

Uber later introduced Domain-Oriented Microservice Architecture (DOMA) and adopted Apache Thrift to standardize APIs across services.

 

Additionally, investments in service discovery, distributed tracing (Jaeger), and observability became central to sustaining service reliability.

 

DoorDash: Controlled Consolidation

DoorDash learned key system architecture lessons from early microservices adoption, leading to a more consolidated and modular approach:

  • Poor service discoverability
  • Duplicate logic across domains
  • On-call burden due to inter-service dependencies

 

Their solution involved selectively merging microservices and prioritizing modular design over fine-grained service decomposition. They also invested in developer onboarding, internal service catalogs, and unified deployment processes to address structural and organizational complexity. 

Common Patterns, Symptoms, and Strategic Interventions

Recognizable Smells of System Architecture Debt:

  • All-hands deployments (monolith indicator)
  • Unclear service boundaries or ownership
  • Unpredictable runtime behavior due to coupling
  • Low testability or integration stability
  • High operational burden from fragmented tooling or inconsistent pipelines

 

Proven Patterns for Resolution:

  • Strangler Fig Pattern: Incremental rewrites of legacy systems
  • Circuit Breakers & Bulkheads: Resilience patterns to isolate failures
  • Macroservices: A compromise between monoliths and microservices
  • Paved Path/Golden Path Platforms: Promote consistent service scaffolding
  • ADRs (Architecture Decision Records): Create traceability for evolution
  • Service Catalogs and Dependency Mapping: Improve visibility and team alignment

 

Principles to Internalize:

  • System architecture must evolve as team topology, scale, and velocity change
  • Debt is inevitable, but it must be intentional, monitored, and managed
  • Effective architecture couples organizational design and infrastructure investment 
System_architecture_ASSIST_Software_5

Architecture as a Living System

A system architecture is never static. The answer is almost always in the architectural design world: it depends. Every decision, whether it's introducing a new architectural layer, breaking apart a monolith, or consolidating services, needs to be evaluated based on product maturity, team structure, and engineering constraints. Success usually involves making deliberate, contextual trade-offs (not following trends or checklists).

 

Effective architecture teams:

  • Monitor system health with metrics like deployment frequency, MTTR, and team-to-team dependency load
  • Invest in platform capabilities to reduce fragmentation and increase consistency
  • Build lightweight governance into delivery workflows, including feedback loops, system architecture reviews, and design documentation.

 

System architecture work isn’t a one-time design exercise. It’s ongoing maintenance. Managing architectural debt means making time to clean up as you grow, or risking that growth getting stuck under its weight.

 

Sources include engineering retrospectives and technical blogs from Monzo, Amazon, Uber, Segment, Khan Academy, Zalando, Riot Games, DoorDash, and others. These cases provide critical insight into how architecture evolves in production and what it takes to keep it healthy at scale.

 

[1]  https://monzo.com/blog/how-we-run-migrations-across-2800-microservices

[2] https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html

[3] https://www.uber.com/blog/service-oriented-architecture

[4] https://segment.com/blog/goodbye-microservices  

[5] https://blog.khanacademy.org/beating-the-odds-khan-academys-successful-monolith%E2%86%92services-rewrite

[6] https://vfunction.com/blog/application-modernization-case-study

[7] https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando

[8] https://www.allthingsdistributed.com/2022/11/amazon-1998-distributed-computing-manifesto.html 

Share on:

* I read and understood the ASSIST Software website's terms of use and privacy policy.

Want to stay on top of everything?

Get updates on industry developments and the software solutions we can now create for a smooth digital transformation.

Section wave outside

Frequently Asked Questions

1. What is ASSIST Software's development process?  

The Software Development Life Cycle (SDLC) we employ defines the following stages for a software project. Our SDLC phases include planning, requirement gathering, product design, development, testing, deployment, and maintenance.

2. What software development methodology does ASSIST Software use?  

ASSIST Software primarily leverages Agile principles for flexibility and adaptability. This means we break down projects into smaller, manageable sprints, allowing continuous feedback and iteration throughout the development cycle. We also incorporate elements from other methodologies to increase efficiency as needed. For example, we use Scrum for project roles and collaboration, and Kanban boards to see workflow and manage tasks. As per the Waterfall approach, we emphasize precise planning and documentation during the initial stages.

3. I'm considering a custom application. Should I focus on a desktop, mobile or web app?  

We can offer software consultancy services to determine the type of software you need based on your specific requirements. Please explore what type of app development would suit your custom build product.   

  • A web application runs on a web browser and is accessible from any device with an internet connection. (e.g., online store, social media platform)   
  • Mobile app developers design applications mainly for smartphones and tablets, such as games and productivity tools. However, they can be extended to other devices, such as smartwatches.    
  • Desktop applications are installed directly on a computer (e.g., photo editing software, word processors).   
  • Enterprise software manages complex business functions within an organization (e.g., Customer Relationship Management (CRM), Enterprise Resource Planning (ERP)).

4. My software product is complex. Are you familiar with the Scaled Agile methodology?

We have been in the software engineering industry for 30 years. During this time, we have worked on bespoke software that needed creative thinking, innovation, and customized solutions. 

Scaled Agile refers to frameworks and practices that help large organizations adopt Agile methodologies. Traditional Agile is designed for small, self-organizing teams. Scaled Agile addresses the challenges of implementing Agile across multiple teams working on complex projects.  

SAFe provides a structured approach for aligning teams, coordinating work, and delivering value at scale. It focuses on collaboration, communication, and continuous delivery for optimal custom software development services. 

5. How do I choose the best collaboration model with ASSIST Software?  

We offer flexible models. Think about your project and see which models would be right for you.   

  • Dedicated Team: Ideal for complex, long-term projects requiring high continuity and collaboration.   
  • Team Augmentation: Perfect for short-term projects or existing teams needing additional expertise.   
  • Project-Based Model: Best for well-defined projects with clear deliverables and a fixed budget.   

Contact us to discuss the advantages and disadvantages of each model. 

ASSIST Software Team Members