The Architect's Toolbox
Choosing Your Foundational Style
Part of the From Patterns to Practice series
From “Why” to “How”
Once you have your drivers, you face the highest-stakes decision in the process: choosing a foundational Architectural Style.
Most people get this wrong because they pick the trendiest tool instead of the one that actually fits their drivers. In my workshops, I see teams jump straight to Microservices because “that is what Netflix does,” without realizing that they do not have the problems of Netflix—or the budget of Netflix.
The world of architectural styles is vast, but for most modern systems, the decision revolves around one question: How will you deploy your code and how will its pieces communicate?
We will focus on the three styles that provide the clearest (and most contrasting) answers: Monolithic, Microservices, and Event-Driven. Understanding the core trade-offs between these three is the prerequisite for everything else.
The Monolithic Style
Your most direct path is the Monolithic style. All code for every part of the business lives in one deployable unit.
For CityPulse, this is an excellent fit for the Time-to-Market driver. The simplicity of a single codebase and one deployment pipeline makes it undeniably the fastest option. For Reliability, it also performs well; a ticket purchase can be a single, atomic database transaction, which is inherently more reliable than a distributed one.
However, it is a poor fit for the critical Throughput Scalability driver. The problem is not that a monolith cannot scale; it is that the scaling is indiscriminate and inefficient. To handle the load on the small Ticketing module, you are forced to pay for 50 extra instances of the entire monolith, including the idle User Profile and Event Organizer modules. You are scaling the whole to serve a tiny, overloaded part.
Architect's Log
There is a pervasive myth that “monoliths do not scale.” It is a lazy oversimplification. The truth is that you pay a “scaling tax” either way. With a monolith, you pay by scaling inefficiently at the application level. With microservices, you pay a heavy, upfront tax in infrastructure and operational complexity. The real question is: which tax are you more willing to pay right now?The Microservices Style
To directly address the scalability driver, you move to the Microservices style.
This style is a perfect fit for your Throughput Scalability target. You can create a TicketingService and scale it independently to meet the 1,000 purchases/sec target while protecting the performance of the rest of the site.
But this introduces a “microservice tax” that is often ignored until it’s too late. Each service needs its own container, runtime, and monitoring. You must consider whether the cost of this distributed overhead is actually greater than the cost of replicating the few lightweight modules in your monolith.
Even worse, this style is a poor fit for your Time-to-Market goal. The upfront complexity of creating a distributed system makes a three-month deadline nearly impossible. It also scores lower on Reliability. A single purchase might now require synchronous calls between three services, introducing “temporal coupling” where a failure in one service brings down the entire chain.
The Distributed Monolith Trap
If you build microservices but they all share a single database and use synchronous calls for everything, you have not built microservices. You have built a “distributed monolith”—all the operational pain of microservices with none of the autonomy. I explore this in detail in the Secret to Modular, Deployable Architecture.The Event-Driven Style
Both previous styles present a stark trade-off. The Event-Driven style offers a different path.
This architecture is an excellent fit for your Throughput Scalability and Performance drivers. Your purchase endpoint could simply write a TicketPurchaseRequested event to a queue and respond immediately, allowing the system to absorb massive traffic spikes. It also scores high on Reliability. By eliminating temporal coupling, the Ticketing process can continue even if the Notifications service is down.
But like microservices, it is a poor fit for a fast launch. It requires a significant upfront investment in message brokers and—more importantly—requires your team to master a new, asynchronous way of thinking.
Architect's Log
Of all the styles, Event-Driven Architecture is the easiest to get wrong. The allure of decoupling is powerful, but I have seen teams create incomprehensible “chains of events” that are impossible to debug. If you cannot clearly trace your core business workflows, you have not designed a resilient system; you have designed chaos. Do not even consider EDA unless you have a rock-solid plan for observability from day one.The Dilemma of Choice
You have moved beyond buzzwords to a nuanced understanding of how each style interacts with your specific business problem. The dilemma is clear: the Monolith wins on speed, Microservices wins on organizational scale, and the Event-Driven style wins on resilience and load absorption.
So, how do you choose? How do you break the tie?
In the next post, we will introduce the final analytical tools in our framework—the Pattern Profiling Scorecard and the Weighted Scoring Matrix—to turn this analysis into a final, data-driven decision.
Further Reading
- Fundamentals of Software Architecture by Mark Richards and Neal Ford. A comprehensive and accessible overview of many architectural styles and patterns.
- “MonolithFirst” by Martin Fowler. The classic and influential article arguing for why starting with a monolith is often a pragmatic choice.
- Building Microservices, 2nd Edition by Sam Newman. The canonical book on the microservices architectural style.
- “What do you mean by ‘Event-Driven’?” by Martin Fowler. A crucial article that clarifies the different patterns and motivations that fall under the broad EDA umbrella.
