Software Architectures Cheat Sheet

Updated 2026-04-29

Next Topic: Software Development Lifecycle (SDLC) Cheat Sheet

🧠Study flashcards on this topic48 cards · spaced repetition→

Software architecture is the high-level structure of a software system that defines how components interact, how responsibilities are divided, and how the system evolves over time. It sits at the intersection of business requirements and technical implementation, serving as the blueprint that determines scalability, maintainability, and long-term success. The right architecture isn't about following trends — it's about matching your system's actual constraints: team size, growth trajectory, complexity tolerance, and operational capabilities. Think of architecture as decision boundaries: each pattern constrains what you can change easily later, so understanding trade-offs upfront prevents costly rewrites down the line.

What This Cheat Sheet Covers

This topic spans 8 focused tables and 48 indexed concepts, 48 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Foundational UI ArchitecturesTable 2: Layered and Modular ArchitecturesTable 3: Distributed System ArchitecturesTable 4: Data-Centric ArchitecturesTable 5: Communication and Integration PatternsTable 6: Resilience and Fault Tolerance PatternsTable 7: Concurrent and Reactive PatternsTable 8: Specialized Architectures

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Foundational UI Architectures

The patterns that organize the presentation layer all wrestle with the same question: how do you keep your UI logic, your data, and the glue between them from collapsing into one tangled mess. The classic MVC/MVP/MVVM family separates those concerns differently, while the unidirectional-flow approaches (Flux, MVI) trade flexibility for predictability, and the newer entries — microfrontends and Islands — rethink the boundary entirely for teams and performance.

Architecture	Example	Description
MVC (Model-View-Controller)	`Model → Controller → View` `User input → Controller updates Model → View re-renders`	• Separates application into three components: Model holds data and business logic, View displays UI, Controller handles user input and updates Model • widely used in web frameworks (Rails, Spring MVC, Laravel) but can lead to tight coupling between Controller and View.
MVVM (Model-View-ViewModel)	`View ← binds to → ViewModel` `ViewModel.property = data` `View auto-updates`	• Introduces ViewModel as intermediary between View and Model using data binding • View observes ViewModel properties and updates automatically • dominant pattern in WPF, MAUI, and modern mobile (SwiftUI, Jetpack Compose) where declarative UIs benefit from reactive bindings.
MVP (Model-View-Presenter)	`View.updateUI(data)` `Presenter handles logic` `View is passive`	• Presenter acts as middle layer between View and Model; View is completely passive (dumb UI) and Presenter contains all presentation logic • improves testability over MVC since Presenter has no framework dependencies • common in Android development pre-MVVM era.
Flux	`Action → Dispatcher → Store → View` `View dispatches new Action`	• Facebook's pattern enforcing unidirectional data flow in React apps • Actions represent events, Dispatcher broadcasts to Stores, Stores hold state and notify Views • prevents complex bidirectional dependencies; foundation for Redux and similar state management libraries.
MVI (Model-View-Intent)	`Intent → Model update → View(state)` `Single immutable state` `Unidirectional flow`	• Enforces unidirectional data flow with a single immutable state (Model); user actions are Intents that trigger state transformations, View renders solely on current state • guarantees predictability, simplifies debugging • gaining traction in Jetpack Compose and SwiftUI.
Three-Tier Architecture	`Presentation (UI)` `Business Logic (API/services)` `Data Access (Database)`	• Classic enterprise pattern dividing system into three physical tiers: presentation layer for UI, logic layer for business rules, data layer for storage • each tier can scale independently • standard for traditional client-server applications.
Microfrontend Architecture	`shell-app` `→ checkout-mfe (Team A)` `→ products-mfe (Team B)` `Module Federation / single-spa`	• Extends microservices philosophy to the frontend: each team owns an independently deployable UI fragment (feature area) • teams use different frameworks, release cadences, and pipelines • Module Federation (webpack 5) is the dominant 2026 integration mechanism; used by IKEA, Spotify, Zalando.
Islands Architecture	`<html> (static HTML)</html>` `<Carousel client:visible />` `<Header client:load />`	• Renders pages as static HTML with opt-in interactive "islands" of JavaScript that hydrate independently in the browser • coined by Katie Sylor-Miller (2019), popularized by Astro; each island loads and hydrates in parallel without blocking others • dramatically reduces JavaScript sent to client; excellent SEO and performance.

Table 2: Layered and Modular Architectures

These patterns govern how you slice a single application internally — whether by horizontal technical layers or by feature — and most of them orbit one big idea: keep your business logic at the center, free of any dependency on frameworks or databases. Clean, Hexagonal, and Onion are three lenses on that same dependency-inversion principle, while Vertical Slice and the Modular Monolith offer alternative cuts that have gained real traction as teams sour on premature microservices.

Pattern	Example	Description
Layered Architecture (N-Tier)	`UI → Business Logic → Data Access → Database` `Each layer depends on layer below`	• Organizes system into horizontal layers with strict dependencies flowing downward; each layer provides services to the layer above and consumes from below • promotes separation of concerns but can lead to performance bottlenecks when all requests traverse every layer.

The rest of this section is part of the full cheat sheet

Table 3: Distributed System Architectures

Once a system outgrows a single process, you enter the world of distributed architectures — and with it, network failures, eventual consistency, and the operational machinery to manage many moving parts. The styles here span the spectrum from microservices and SOA to event-driven and serverless, along with the supporting infrastructure (service discovery, service mesh) and more specialized shapes like space-based and peer-to-peer for extreme scale or decentralization.

Architecture	Example	Description
Microservices Architecture	`Service A, B, C each with own DB` `Communicate via HTTP/gRPC/messaging`	• Structures application as collection of small, independent services each owning its domain and database; services deploy independently and scale separately • enables team autonomy and technology diversity but introduces distributed system complexity (network failures, eventual consistency, distributed tracing).

The rest of this section is part of the full cheat sheet

Table 4: Data-Centric Architectures

When data is the hard part of your system, these patterns reshape how it's stored, owned, and processed. CQRS and Event Sourcing split reads from writes and treat history as the source of truth; Database Per Service and Data Mesh decentralize ownership to the teams closest to the data; and Lambda versus Kappa captures the long-running debate over whether to run separate batch and streaming pipelines or unify everything into one stream.

Pattern	Example	Description
CQRS (Command Query Responsibility Segregation)	`Write Model (Commands)` `Read Model (Queries)` `Separate datastores`	• Separates reads from writes using different models; write model optimized for consistency and validation, read model optimized for query performance • often paired with Event Sourcing for writes and denormalized views for reads; enables independent scaling of read and write workloads.

The rest of this section is part of the full cheat sheet

Table 1: Foundational UI Architectures

Architecture	Example	Description
MVC (Model-View-Controller)	`Model → Controller → View` `User input → Controller updates Model → View re-renders`	• Separates application into three components: Model holds data and business logic, View displays UI, Controller handles user input and updates Model • widely used in web frameworks (Rails, Spring MVC, Laravel) but can lead to tight coupling between Controller and View.
MVVM (Model-View-ViewModel)	`View ← binds to → ViewModel` `ViewModel.property = data` `View auto-updates`	• Introduces ViewModel as intermediary between View and Model using data binding • View observes ViewModel properties and updates automatically • dominant pattern in WPF, MAUI, and modern mobile (SwiftUI, Jetpack Compose) where declarative UIs benefit from reactive bindings.
MVP (Model-View-Presenter)	`View.updateUI(data)` `Presenter handles logic` `View is passive`	• Presenter acts as middle layer between View and Model; View is completely passive (dumb UI) and Presenter contains all presentation logic • improves testability over MVC since Presenter has no framework dependencies • common in Android development pre-MVVM era.
Flux	`Action → Dispatcher → Store → View` `View dispatches new Action`	• Facebook's pattern enforcing unidirectional data flow in React apps • Actions represent events, Dispatcher broadcasts to Stores, Stores hold state and notify Views • prevents complex bidirectional dependencies; foundation for Redux and similar state management libraries.
MVI (Model-View-Intent)	`Intent → Model update → View(state)` `Single immutable state` `Unidirectional flow`	• Enforces unidirectional data flow with a single immutable state (Model); user actions are Intents that trigger state transformations, View renders solely on current state • guarantees predictability, simplifies debugging • gaining traction in Jetpack Compose and SwiftUI.
Three-Tier Architecture	`Presentation (UI)` `Business Logic (API/services)` `Data Access (Database)`	• Classic enterprise pattern dividing system into three physical tiers: presentation layer for UI, logic layer for business rules, data layer for storage • each tier can scale independently • standard for traditional client-server applications.
Microfrontend Architecture	`shell-app` `→ checkout-mfe (Team A)` `→ products-mfe (Team B)` `Module Federation / single-spa`	• Extends microservices philosophy to the frontend: each team owns an independently deployable UI fragment (feature area) • teams use different frameworks, release cadences, and pipelines • Module Federation (webpack 5) is the dominant 2026 integration mechanism; used by IKEA, Spotify, Zalando.
Islands Architecture	`<html> (static HTML)</html>` `<Carousel client:visible />` `<Header client:load />`	• Renders pages as static HTML with opt-in interactive "islands" of JavaScript that hydrate independently in the browser • coined by Katie Sylor-Miller (2019), popularized by Astro; each island loads and hydrates in parallel without blocking others • dramatically reduces JavaScript sent to client; excellent SEO and performance.

Table 2: Layered and Modular Architectures

Pattern	Example	Description
Layered Architecture (N-Tier)	`UI → Business Logic → Data Access → Database` `Each layer depends on layer below`	• Organizes system into horizontal layers with strict dependencies flowing downward; each layer provides services to the layer above and consumes from below • promotes separation of concerns but can lead to performance bottlenecks when all requests traverse every layer.

Table 3: Distributed System Architectures

Architecture	Example	Description
Microservices Architecture	`Service A, B, C each with own DB` `Communicate via HTTP/gRPC/messaging`	• Structures application as collection of small, independent services each owning its domain and database; services deploy independently and scale separately • enables team autonomy and technology diversity but introduces distributed system complexity (network failures, eventual consistency, distributed tracing).

Table 4: Data-Centric Architectures

Pattern	Example	Description
CQRS (Command Query Responsibility Segregation)	`Write Model (Commands)` `Read Model (Queries)` `Separate datastores`	• Separates reads from writes using different models; write model optimized for consistency and validation, read model optimized for query performance • often paired with Event Sourcing for writes and denormalized views for reads; enables independent scaling of read and write workloads.