Whether you’re watching a gripping documentary on Netflix or any other OTT platform, witnessing a nail-biting Test match at Old Trafford, or placing an order on an e-commerce platform, you’re experiencing the result of great software architecture in action.
I find it fascinating to explore the powerful software architectures that make modern applications so reliable and scalable.
These real-time, large-scale systems handle pressure, recover from failures, and scale effortlessly because engineers design them with resilience, availability, fault tolerance, scalability, robustness, performance, recoverability, and continuity in mind.
Architects and development teams brainstorm, evaluate trade-offs, and envision the architecture that allows these applications to serve millions smoothly and reliably.
I drew inspiration for this blog post from the book Fundamentals of Software Architecture – An Engineering Approach, written by Mark Richards and Neal Ford.
In this post, I’ll explain the main architecture styles and patterns that help build powerful systems and show how these choices shape the software we use every day.
Architecture is about the important stuff … whatever that is
— Ralph Johnson
Before we dive into those patterns, let’s first understand some fundamental terminology.
What is software architecture?
We often see various definitions of software architecture – some call it the blueprint of a system, while others describe it as a roadmap for development. However, these definitions rarely explain what the blueprint or roadmap actually includes.
A more complete definition describes software architecture as the combination of the system’s architecture and the architecture characteristics (the ‘-ilities’ it must support), the key architectural decisions, and the core design principles.
Succinctly put:
Software Architecture = Architecture Characteristics + Architecture Decisions + Design Principles
Laws of Software Architecture
- First Law: Everything in software architecture is a trade-off
- Second Law: Why is more important than how
Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
Conway’s Law
What are architecture styles/patterns?
Occasionally, people refer to architecture styles as architecture patterns—named relationships between components that address various architecture characteristics. When I mention architecture characteristics, I’m referring to qualities such as
- Availability
- Reliability
- Testability
- Scalability
- Security
- Agility
- Fault tolerance
- Elasticity
- Recoverability
- Performance
- Deployability
- Learnability
Understanding Architecture Styles: Monolithic vs Distributed
Software architecture styles fall into two main categories: monolithic and distributed. Each style comes with its own challenges and trade-offs. The choice depends entirely on the business requirements, scalability needs, and team capabilities.
Monolithic Architecture
In a monolithic approach, all application components live within a single deployment unit. This style is further divided into:
Layered architecture
It organizes code into layers such as presentation, business, persistence, and data access – and is also known as n-tier architecture. Enterprise organizations often adopt this style because it allows specialized teams to work on separate layers: frontend developers handle the presentation layer, backend developers manage the business and data access layers, and database engineers take care of database operations.
Layered architecture comes in different variants that include the presentation, business, persistence, and database layers.
- First variant: Combines the presentation, business, and persistence layers into a single deployment unit, while the database layer exists as an external physical database.
- The second variant places the presentation layer and database layer in separate deployment units and combines the business and persistence layers into another deployment unit.
- The third variant combines all four layers into a single deployment unit.
Each layer carries a distinct responsibility and maintains abstraction:
- Presentation Layer: Displays information to users in a defined format and manages browser communication logic.
- Business Layer: Executes the specific business rules tied to a request.
- Persistence Layer: Performs database operations such as fetching and saving information.
- Database Layer: Stores, retrieves, and maintains data.
Pipeline architecture
This architecture, also known as the Pipes and Filter pattern, comes into play when architects and developers decide to split functionality into discrete, independent components. It follows the principles of Unix shell environments, such as Bash and Zsh, where each component performs a specific task and passes its output to the next.
Pipes act as communication channels between filters. Each pipe forms a unidirectional, point-to-point connection between filters. For performance reasons, a pipe accepts input from one source and always directs its output to another.
Filters are self-contained, independent from one another, and generally stateless. Each filter performs a single, well-defined task. Together, they achieve the overall process by executing their tasks in sequence.
There are four main types of filters:
- Producer: Serves as the starting point of the process and acts as the data source.
- Transformer: Accepts input from the source, converts it into a different format, and forwards it to the next pipe. This step is optional.
- Tester: Accepts input, performs one or more conditional checks, and yields results if any criteria are met.
- Consumer: Acts as the endpoint of the pipeline, where the final result is produced. From here, the result can be stored in a persistent database or displayed in the frontend interface.
REAL-WORLD USE:
- In DevOps culture, Jenkins serves as one of the best examples of the pipeline architecture style.
Microkernel architecture
It separates a minimal functional core from extended features and customer-specific parts and is also referred to as a plug-in architecture.
Simply put, it is a simple monolithic style consisting of two main components: a core system and plug-in components.
- Core system: It provides extensibility, adaptability, and isolation of application features from customer-specific logic.
- Plug-in Components: Contain application logic divided into independent modules that extend or customize the core system’s functionality.
It comes in different variants
- Layered Core System: Technically partition the core into distinct layers
- Modular Core System: Partition the core based on domains
- Embedded User Interface: Build the frontend separately and embed it into the core system, which provides backend services, and deploy it as a single unit.
- Separate User Interface: Deploy the user interface and core system as multiple units, with the user interface and core system each being separate deployment units, following the microkernel pattern.
REAL-WORLD USE:
- Most modern Integrated Development Environments (IDEs) are like IntelliJ, Eclipse, JIRA Software, and Jenkins.
- And many modern browsers, like Chrome and Firefox, use this architectural style.
For all the above architecture styles, each one has advantages and challenges. Let’s discuss the advantages and challenges of each style in the next section, based on architectural characteristics.
Best-Fit Use Cases
Layered architecture works well for small, simple applications or websites, especially when you have a limited budget and tight deadlines. It also suits situations where an architect is still analyzing business needs and is unsure which architecture style fits best. This approach aligns well with architectural characteristics such as low overall cost and simplicity.
Not a Good Fit For
Although layered architecture can be effective during the initial development phase, it shows significant drawbacks as the application grows. Architectural characteristics such as maintainability, agility, testability, performance, elasticity, scalability, fault tolerance, and deployability often suffer, making it less suitable for large, complex, or rapidly evolving systems.
Performance in layered architecture is not a natural fit for high-performance systems due to its lack of parallel processing and closed layering. While techniques like caching and multithreading can improve performance, they are not inherent characteristics of this architectural style.
And fault tolerance and layered architecture also fall short because of their monolithic deployment model and limited architectural modularity. If one layer fails due to a catastrophic issue, the entire system can go down—leading to service outages and a poor customer experience.
In my upcoming article, I will explore the different types of distributed architecture.
Stay tuned!
Happy Reading!
References
- Book: Fundamentals of Software Architecture: An Engineering Approach by Mark Richards & Neal Ford
