7 kinds of Architectures that any software engineer should know about

Building the skills for modern programmers

11 min readApr 29, 2024

As we’ve covered many times, reading engineering blogs from various companies is the best way to level up your system design skills. However, to maximize your learning, it’s important to have a strong understanding of the basics. Understanding the different kinds of software architectures is one such foundational piece that you must know. Software architecture defines the fundamental structure of your application, deeply influencing factors like scalability, maintainability, and the speed of development. Choosing wisely is paramount for a project’s success. In today’s edition of Tech Made Simple, we will be exploring 7 common architectures:

Monolithic Architecture: The traditional approach. Here your entire application is built as a single, self-contained unit. Monoliths are simple, easy to deploy, and cost-effective- making them suitable for smaller projects or rapid prototyping.
Service-Oriented Architecture (SOA): A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently. SOA is a software architecture style that focuses on building applications using discrete, reusable services that communicate with each other via well-defined protocols over a network. This emphasizes loose coupling and interoperability, allowing different systems built with various technologies to work together easily.
Microservices Architecture: Microservices enable scalability, fault isolation, and independent deployment by splitting your app into loosely coupled services. This makes them ideal for large, complex systems requiring flexibility and continuous evolution. However, they can be very costly if not done correctly, which is why it’s important to put more effort into them.
Event-Driven Architecture (EDA): A reactive approach where components communicate through events. EDA enables decoupled systems, scalability, and real-time processing, making it suitable for event-based applications and complex business workflows.
Layered Architecture: An architectural style that separates components into logical layers, such as presentation, business logic, and data access. Layered architectures promote the separation of concerns, maintainability, and code reusability.
Domain-Driven Design (DDD): An approach that focuses on modeling the application domain and its concepts. DDD emphasizes collaboration between domain experts and developers, ensuring the software aligns closely with the problem domain. This approach can get very complex and costly, which is why people recommend using this only when there is a clear need (we’ll touch upon this later in this article).
Serverless Architecture: A cloud-native approach where developers focus on writing code without managing the underlying infrastructure. Serverless architectures offer scalability, cost optimization, and rapid development, but might lead to strong platform dependence. Nonetheless, there is a clear trend towards larger adoption of serverless, and any modern software engineer should understand it well.

Let’s get into these in more detail.

1. Monolithic Architecture

“So my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.”
-Microservice Premium, Martin Fowler

The Essence: Imagine your application as a single, large block. In a monolith, all components — the user interface (UI), business logic, and database access — are tightly interwoven. Imo, their simplicity makes monoliths a good default for starting your design and switching to something else as your needs differ.

A good representation of the first 3 ideas we cover. Image Source

Advantages:

Simplicity: Monoliths are straightforward to develop, deploy, and test initially.
Cost-Effective for Small Projects: For small teams or applications with limited scope, monoliths can be a quick and efficient way to get started.

Drawbacks:

Scalability Limits: As your application grows, scaling a monolith becomes cumbersome. Changing one part can impact the whole system.
Tight Coupling: Components are so interdependent that it hinders individual updates or technology upgrades. It’s like trying to fix a single faulty brick in a giant, solid wall.
Barrier to New Developers: The sheer size and interconnectedness make it harder for new team members to get up to speed. Any architectural complexity can be 10x more daunting with monoliths since everything ties together.

2. Service-Oriented Architecture (SOA)

“Complexity can neither be created nor destroyed, only moved somewhere else.”
-Tesler’s Law.

The Essence: An evolution of older distributed architectures, focusing on reusable services that communicate via standard protocols (like SOAP or web services).

Advantages:

Loose Coupling: Services are not tightly intertwined, reducing dependency issues.
Reusability: Services are designed to be ‘black boxes’, used by different applications within an organization.
Technology Agnostic: SOA can integrate systems built with different languages or platforms. To quote Thomas Erl, CEO of Arcitura Education Inc., “SOA helped free us from the tech vendor lock-in model that we had a decade ago, in terms of motivating the transition towards interoperability level standards.”

Drawbacks:

Complexity: The overhead of standardized protocols introduce design and management complexity.
Performance Overhead: SOA often has slower communication compared to tightly coupled systems.

3. Microservices Architecture

The Essence: Break down your monolith into small, independent services. Each microservice focuses on a specific business function and has its own database (if needed). Services communicate via well-defined APIs (think REST or messaging protocols).

Advantages:

Independent Scalability: Scale up only the services under heavy load, not the entire system.
Resiliency: If one microservice fails, it doesn’t take down the whole application.
Technology Freedom: Each microservice can be built with the best-suited technology (language, database) for its task.

Drawbacks:

Increased Complexity: Distributed systems are inherently more complex to design, troubleshoot, and monitor.
Operational Overhead: Deploying and managing numerous microservices adds workload for teams.
Network Reliance: Increased reliance on network communication brings latency, potential failure points.

Using microservices is like pulling guard in a cage fight- if you’re not very good at what you do, you’re screwing yourself. Last year, Amazon found out about this the hard way- “Moving our service to a monolith reduced our infrastructure cost by over 90%.”

4. Event-Driven Architecture (EDA)

The Essence: Components communicate indirectly by publishing and subscribing to events. An event broker orchestrates this communication. EDA can easily blend with other methods. Chances are that most apps you use regularly have a strong event-driven component (clicks on Social Media, typing messages, games, etc.)

Advantages:

Extreme Decoupling: Components don’t need to know about each other, just the events they care about.
Scalability: Adding new components that listen to existing events is easy.
Real-Time Capability: Ideal for systems needing immediate reaction to data changes or user interactions.

Drawbacks:

Mental Shift: Requires developers to think in terms of events, not direct function calls.
Debugging Challenges: Tracing the flow of events in a complex EDA system can be tricky.
Eventual Consistency: Not all parts of the system may be updated immediately after an event, depending on how it’s set up.

Amazon has a really good intro to EDA + further sources over here-

5. Layered Architecture

The Essence: Another classic approach where the application is organized into layers like presentation, business logic, data access. Each layer interacts only with the layer below, enforcing clear boundaries. These are one of the fundamental patterns that we also touched upon earlier.

Advantages:

Separation of Concerns: Improves code organization, making each layer easier to understand and modify.
Maintainability: Changes contained within a layer often don’t affect the rest of the system.
Testability: Layers can be tested independently.

Drawbacks:

Performance Impact: Passing data through multiple layers can add overhead.
Flexibility Concerns: Strict layering can sometimes hinder cross-cutting concerns that necessitate communication across layers.

6. Domain-Driven Design (DDD)

The Essence: DDD is less a technical architecture and more a design philosophy. It emphasizes modeling the software system as a direct reflection of the real-world business domain and its complexities. The philosophy of DDD is something that all of Tech should take to heart, b/c too many tech products look to ‘disrupt’ industries w/o understanding the domain enough.

Ignoring cultural intelligence can lead to billions of dollars spent, only to come back to the place we started. A lot of tech companies have recently realized this. Uber, Spotify, and Crypto were introduced as disruptors that would innovate upon their old entrenched industries, bypassing regulations and providing access directly to the people. All of these have ended up becoming precisely the monster they set out to slay.
-Why Data is an Incomplete Representation of Reality

Advantages:

Aligns Software with Business: Developers and domain experts use a shared language
Deeper Understanding: The development process leads to a greater understanding of the business domain itself.
Evolving Codebase: The software can evolve alongside the business more organically.

Drawbacks:

High Upfront Investment: DDD requires dedicated effort to understand the domain and build a shared vocabulary. Domain expertise is generally costly, especially for specialized cases like finance, law, and medicine.
Complexity: DDD introduces patterns like Bounded Contexts, Aggregates, and Ubiquitous Language, adding complexity for development teams.
Not One-Size-Fits-All: DDD is most beneficial for applications with complex business logic. It might be overkill for simpler systems.

Microsoft has an excellent analysis of DDD over here. I’m quoting a large chunk below, but would recommend checking out the source for more-

“As the core of the software is the domain model, which is a direct projection of this shared language, it allows the team to quickly find gaps in the software by analyzing the language around it. The creation of a common language is not merely an exercise in accepting information from the domain experts and applying it. Quite often, communication problems within development teams are due not only to misunderstanding the language of the domain, but also due to the fact that the domain’s language is itself ambiguous. The Domain Driven Design process holds the goal not only of implementing the language being used, but also improving and refining the language of the domain. This in turn benefits the software being built, since the model is a direct projection of the domain language.

In order to help maintain the model as a pure and helpful language construct, you must typically implement a great deal of isolation and encapsulation within the domain model. Consequently, a system based on Domain Driven Design can come at a relatively high cost. While Domain Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.

The following are the main benefits of the Domain Driven Design style:

Communication. All parties within a development team can use the domain model and the entities it defines to communicate business knowledge and requirements using a common business domain language, without requiring technical jargon.
Extensible. The domain model is often modular and flexible, making it easy to update and extend as conditions and requirements change.
Testable. The domain model objects are loosely coupled and cohesive, allowing them to be more easily tested.

Consider DDD if you have a complex domain and you wish to improve communication and understanding within your development team, or where you must express the design of an application in a common language that all stakeholders can understand. DDD can also be an ideal approach if you have large and complex enterprise data scenarios that are difficult to manage using other techniques.”

7. Serverless Architecture

The Essence: A cloud-based model where you don’t manage servers directly. Code runs in ephemeral functions triggered by events (like HTTP requests, file uploads), and providers (AWS Lambda, Azure Functions) handle the rest.

Advantages:

Ultimate Scalability: Functions scale up and down automatically based on demand. This leverages economies of scale- it’s cheaper for AWS to buy heaps and compute and give you a small portion wholesale than it is for you to go through the effort of buying and maintaining cloud capabilities for yourself.
Pay-Per-Use: You only pay for function executions, not idle servers.
Faster Development: Focus purely on code, not infrastructure management.

Drawbacks:

Vendor Lock-In: Migrating between serverless providers can be challenging.
Cold Starts: Functions inactive for a while can have a delay when first triggered.
Debugging and Observability: Limited control over the execution environment brings some monitoring challenges.

Serverless is a very noob-friendly meta, which is why more and more organizations are looking to invest into serverless computing-

Taken from our intro to serverless computing here.

However, serverless computing comes with a huge hidden risk- one badly designed infinite loop, and you will be making an intimate connection with organ sellers to pay off your bills. This is why it’s very important to invest heavily into DevOps and monitoring to catch any such problems before they Sergio Ramos your budget into the ground.

My goal with such surveys (and my articles in general) is not to be the final authority on these topics. It’s to provide a base that encourages you to explore these ideas on your ideas (and hopefully to get you to share your learnings back with me). If any of my articles inspire to look deeper into the topics discussed, I’d consider my work done. To that end, let me know what I can do better.

Ready to simplify your tech journey? Subscribe to Technology Made Simple and get clear, actionable insights to boost your tech skills and career. Forget wasting time on endless tutorials — find everything you need in one place.

Special Offer: Save 20% on your first year! Here’s what you get:

Monthly Plan: 640 INR (8 USD) [Originally 800 INR]
Yearly Plan: 6400 INR (80 USD) [Originally 8000 INR]

Still hesitant? Try risk-free with our 6-month money-back guarantee. If you’re not satisfied, get a full refund, no questions asked! All you have to do is message me.