Evolving Systems: A Guide to Minimum Viable Architecture¶

In the world of software engineering, there's a tempting desire to build the perfect, infinitely scalable architecture from day one. However, as veteran architect Randy Shoup explains in his talk at YOW! 2022, this is often a path to failure. The key takeaway is that architecture is not a static blueprint; it's an evolutionary journey that must align with the changing needs of the business. There is no one-size-fits-all solution.

This post summarizes Shoup's concept of "Minimum Viable Architecture," exploring how your system's design should adapt as your product moves from a simple idea to a globally scaled platform.

The Journey of Giants: eBay and Amazon¶

Shoup begins by looking at the architectural history of giants like eBay and Amazon.

eBay (1999): Started as a massive C++ monolith connected to a single, gigantic Oracle database. It was incredibly successful but became a bottleneck, leading to a multi-year re-architecture effort towards a more distributed system.
Amazon (2001): Similarly, Amazon began with a monolithic application server connected to a large database. By 2001, this "brittle" architecture was hindering their ability to innovate. This led to the famous mandate from Jeff Bezos to move towards independent, service-oriented teams with clear APIs—the birth of their microservices architecture.

The lesson from these stories is clear: the architecture that gets you started is rarely the one that will sustain you at scale.

Phase 1: The "Prototype" - In Search of an Idea¶

When you're just starting, the primary goal isn't to build a scalable system; it's to validate an idea and find a product-market fit.

Goal: Maximize learning and iteration speed.
Constraints: Limited time, money, and people.
Minimum Viable Architecture: A simple monolith. This could be a single application (e.g., a Rails or Django app) connected to a single database.

At this stage, the biggest risk is building something nobody wants. The architecture should be optimized for rapid development and pivoting, not for handling millions of users. A monolith is perfect for this, as it's simple to build, deploy, and change quickly.

Phase 2: The "Just Enough" Architecture - Building the Business¶

Once you've found product-market fit, the focus shifts to building a sustainable business.

Goal: Add features, acquire customers, and build a repeatable business model.
Minimum Viable Architecture: A Modular Monolith.

The monolithic structure is still the right choice for most companies at this stage, as it keeps the team focused and efficient. However, it's crucial to enforce modularity within the monolith. Think of it as creating "namespaces" or "packages" with well-defined boundaries inside the single codebase. This discipline prevents the monolith from becoming an unmanageable "big ball of mud" and paves the way for future evolution.

During this phase, establishing engineering excellence is key. Practices like Continuous Delivery and the use of Feature Flags are vital. They decouple deployment from release, allowing you to ship code continuously while controlling what users see, which is essential for both testing and incremental rollouts.

When Is It Time to Re-architect?¶

Moving away from the monolith is a significant, expensive, and risky decision. Shoup emphasizes that you should only do it when you have no other choice. The primary driver is usually organizational scaling. When your engineering team grows so large that the monolith becomes a bottleneck to productivity—with teams constantly stepping on each other's toes—it's time to consider a change.

Phase 3: The "Scalable" Architecture - From Monolith to Microservices¶

When the pain of the monolith outweighs the pain of re-architecting, you enter the scaling phase.

Goal: Scale the organization and the system.
Minimum Viable Architecture: Microservices.

The move to microservices allows you to scale your teams independently. Each team can own a service (or a set of services), allowing them to develop, deploy, and scale their part of the system without being blocked by others.

Shoup stresses the importance of an incremental migration. A "big bang" rewrite is almost always a mistake. Instead, follow a proven pattern: 1. Don't rewrite, refactor: Gradually carve out services from the existing monolith. 2. Identify seams: Use the modules you defined in the "Just Enough" phase as natural boundaries for your new microservices. 3. Extract services one by one: Pick a component, build it as a separate service, and strangle the old monolithic implementation by redirecting calls to the new service. 4. Use an event-driven approach: Asynchronous events are excellent for decoupling services and ensuring resilience.

Phase 4: The "Stable" or "Optimizing" Architecture¶

Once the migration is largely complete, the architecture enters a more stable phase. The goal shifts to optimizing for cost, performance, and resilience. This might involve fine-tuning services, exploring different data stores, or investing in more sophisticated infrastructure. The key is that the architecture is now flexible enough to allow for continuous, targeted improvements.

Conclusion¶

The concept of a Minimum Viable Architecture teaches us that software architecture is a living thing. By matching your architecture to the current phase of your business, you can avoid premature optimization and focus your resources on what truly matters at each stage. Start simple, maintain modularity, and only embrace the complexity of distributed systems when the pain of your current success forces you to.

Original video: Minimum Viable Architecture • Randy Shoup • YOW! 2022 ```