Architecture Styles & Patterns

Explore common architecture styles and patterns, their trade-offs, and when to use them. Visual diagrams help you understand structure and relationships.

📐

Featured Patterns

Layered Architecture

aka n-tier

Organize code into layers (presentation, business, persistence, database) with clear responsibilities and boundaries (often deployed across N‑tiers).

presentationbusinesspersistencedatabase
Explore Pattern Details →
Layered ArchitectureFour-layer architecture showing presentation, business, persistence, and database layers with top-down dependencies and clear separation of concerns.Layered Architecture👤 Users / External Clients🖥️ Presentation LayerWeb ControllersREST APIsInput ValidationViews/DTOs⚙️ Business LayerDomain ServicesBusiness RulesUse CasesWorkflows💾 Persistence LayerRepositoriesData AccessORM/MappersCaching🗄️ Database LayerPostgreSQLMongoDBRedis CacheFile SystemMessage QueueHTTPLogicDataStorageDependenciesflow downwardHigher layersdepend onlower layersBenefits: Clear separation • Easy testing • Well-understood • Good for CRUD apps

Microservice Architecture

Independent, deployable services aligned to business domains, communicating via APIs, events, or streams.

domainindependent deployapievents
Explore Pattern Details →
Microservice ArchitectureIndependent services communicating via APIs and events, each owning its data and deployment.API GatewayRouting, Auth, Rate LimitingUser Service• Registration• Authentication• Profile MgmtOrder Service• Order Processing• State Management• Business LogicPayment Service• Payment Processing• Fraud Detection• RefundsNotification Service• Email• SMS• PushEvent Bus / Message QueueUser DBPostgreSQLOrder DBMongoDBPayment DBPostgreSQLNotification CacheRedisKey Benefits:• Independent deployment & scaling• Technology diversity per serviceCommunication:• Synchronous: HTTP/gRPC• Asynchronous: Events/Messages

Cell‑Based Architecture

aka CBAaka cell architecture

A decentralized, cloud‑native reference architecture where independently deployable ‘cells’ act as self‑contained units exposing APIs/events, each with its own gateway and control, enabling enterprise‑level agility, modularity, and governance.

celldecentralizedcloud nativegovernance
Explore Pattern Details →
Cell‑Based ArchitectureCells as self‑contained units with gateways and clear interfaces communicating via APIs/events.Cell‑Based ArchitectureCell A – GatewayServices & IntegrationsData / MessagingPolicies / ObservabilityCell B – GatewayBusiness LogicEvents / StreamsSecurity PoliciesCell C – GatewayChannel / APIsData / CacheObservabilityCells expose APIs/events via gateways; compose safely with policy and observability.

Event-Driven Architecture

Systems communicate through events, enabling loose coupling, async workflows, and reactive behavior.

eventspub/subasyncstreaming
Explore Pattern Details →
Event-Driven ArchitectureEvent-driven systems showing messaging patterns (pub/sub) and streaming patterns (event logs) with producers, brokers, and consumers.Event-Driven Architecture📨 Message-Based Events🌊 Stream-Based EventsProducer AOrder ServiceProducer BUser ServiceProducer CPayment ServiceMessage BrokerTopics & QueuesAt-least-onceConsumer 1Email ServiceConsumer 2AnalyticsConsumer 3Audit Service✓ Decoupled producers/consumers✓ Load balancing & competing consumers✓ Guaranteed delivery with retries & DLQProducer AClick EventsProducer BIoT SensorsProducer CCDC EventsEvent StreamPartitioned LogRetention & ReplayConsumer AReal-time MLConsumer BData LakeConsumer CDashboard✓ High throughput & low latency✓ Event replay & time-travel queries✓ Partitioning & parallel processingKey Benefits: Loose coupling • Scalability • Resilience • Real-time processing

Hexagonal Architecture

aka ports and adapters

Domain-centric design separating core logic from external concerns via ports (interfaces) and adapters.

portsadaptersdomaintesting
Explore Pattern Details →
Hexagonal ArchitectureDomain core surrounded by ports and adapters, showing dependency inversion and external system integration.🏛️ Hexagonal Architecture🎯 Domain Core• Business Logic• Domain Entities• Use Cases📥 Driving Side(User initiates)📤 Driven Side(Infrastructure)🌐 API PortWeb Interface⚡ Command PortBusiness Operations🔍 Query PortRead Operations💾 Repository PortData Persistence📨 Event PortMessaging & Events🌍 External API PortThird-party ServicesREST Controller• HTTP/JSON• OpenAPICLI Adapter• Command Line• Batch JobsGraphQL Adapter• Query Interface• SchemaDB Adapter• PostgreSQL• ORM/SQLMessage Adapter• Kafka• RabbitMQHTTP Client• External APIs• REST/SOAP🎯 Key PrincipleDependencies point inward toward the domainInfrastructure depends on business logic, never vice versaBenefits: Testability • Independence • Flexibility • Clean DependenciesDomain CorePorts (Interfaces)Adapters (Implementations)External Systems

Zero-Trust Security Architecture

Never trust, always verify. Security model assuming breach and requiring verification for every access request.

zero trustverificationleast privilegeidentity
Explore Pattern Details →
Zero Trust Security ArchitectureNever trust, always verify security model with identity verification, network segmentation, and continuous monitoring.🔒 Zero Trust Security⚠️ External Threats• Malicious Actors• Advanced Persistent Threats• Zero-day Exploits🎯 Core Principle"Never Trust,Always Verify"Assume Breach👤 Identity & Access Management🔐 MFAMulti-FactorAuthentication📱 Device TrustDevice Health& Compliance⚖️ Risk EngineBehavioralAnalytics📋 Policy EngineAccess Control& Policies🛡️ Network Micro-Segmentation🌐 DMZ ZoneExternal Access🖥️ App ZoneApplication Tier🗄️ Data ZoneSensitive Data👨‍💼 Admin ZonePrivileged Access🛡️ Protected Resources & Assets🌐 Web Apps• SPA/MPA• Dashboards• Portals🔌 APIs• REST/GraphQL• Microservices• Webhooks🗃️ Databases• SQL/NoSQL• Data Lakes• Warehouses📁 File Systems• Object Storage• NAS/SAN• Document Mgmt⚙️ Services• Cloud Services• Legacy Systems• Third-party📱 Devices• Laptops/Mobile• IoT Devices• Servers📊 Continuous Monitoring & Analytics• Real-time threat detection • Behavioral analytics • Compliance monitoring• Risk scoring • Incident response • Security orchestration🎯 Key Principles✅ Verify Explicitly🔒 Least Privilege💣 Assume Breach📈 Continuous Monitor🔄 Dynamic Policies🎛️ Context Aware🛡️ Defense in Depth📍 Data-centric🚫 Never TrustBenefits: Enhanced security posture • Reduced attack surface • Improved compliance • Better visibility

API Security Gateway Pattern

Centralized security enforcement for APIs including authentication, authorization, rate limiting, and threat protection.

api gatewaysecurityrate limitingauthentication
Explore Pattern Details →
API Security Gateway ArchitectureAPI gateway with security layers including WAF, authentication, rate limiting, and threat protection.🛡️ API Security Gateway🌐 Internet / Threats💻 Web ClientsBrowsers, SPAs📱 Mobile AppsiOS, Android🤝 Partner SystemsB2B Integration🚨 Malicious TrafficBots, Attacks⚖️ Load Balancer• SSL Termination• DDoS Protection• Health Checks🔐 API Security GatewaySecurity Layers:🔥 Web Application FirewallOWASP Top 10 Protection🔑 Authentication & AuthorizationOAuth2, JWT, API Keys🚦 Rate Limiting & ThrottlingQuota Management, Circuit Breaker✅ Request/Response ValidationSchema Validation, Data Sanitization🔄 Routing & TransformationLoad Balancing, Protocol Translation📊 Logging & Monitoring🏢 Backend Services👥 User ServiceProfile, Auth📦 Order ServiceE-commerce💳 Payment ServiceBilling, Charges📞 NotificationEmail, SMS🏛️ Legacy SystemsMainframe, SOAP🗄️ DatabasesSQL, NoSQL☁️ Cloud ServicesAWS, Azure🏛️ IdentityProviderOAuth2/OIDC📊 SIEMAnalyticsSecurity EventsBLOCKED🛡️ Security Capabilities• OWASP Top 10 Protection • DDoS Mitigation • Bot Detection • Certificate Management• Real-time Threat Intelligence • Compliance Reporting • Zero-Trust Enforcement• API Discovery • Vulnerability Scanning • Behavioral Analytics • Forensic Logging

Data Encryption Patterns

Comprehensive data protection using encryption at rest, in transit, and in use, with proper key management.

encryptionkey managementdata protectiontls
Explore Pattern Details →
Data Encryption PatternsComprehensive data encryption covering at rest, in transit, and in use with key management and compliance frameworks.🔐 Data Encryption Patterns🗝️ Key Management System (KMS)🏛️ Hardware SecurityModule (HSM)🔄 Key RotationAutomated📦 Envelope EncryptionDEK + KEK Pattern🛡️ Key EscrowRecovery🔐 Access ControlRBAC + Policies🚀 Encryption in Transit💻 ClientBrowser/App🌐 ServerAPI GatewayTLS 1.3🔒 Protocols & Standards• HTTPS/TLS 1.3 • QUIC• Certificate Pinning • HSTS💾 Encryption at Rest🗄️ DatabaseTDEAES-256📁 File SystemBitLocker/LUKSFull Disk☁️ Object StorageS3/BlobServer-side⚙️ ApplicationField LevelColumn Encrypt🔑 Key HierarchyMaster → Data Keys🧠 Encryption in Use🔢 Homomorphic EncryptionCompute on Encrypted Data🏰 Secure Enclaves (TEE)Intel SGX, ARM TrustZone• Zero-knowledge proofs • Confidential computing📋 Regulatory Compliance Frameworks🇪🇺 GDPRData Protection🏥 HIPAAHealthcare💳 PCI-DSSPayment Cards🔒 SOC 2Security Controls🏛️ FedRAMPGovernment🌍 ISO 27001Info Security🌐 NISTCybersecurity🔐 Encryption Standards & AlgorithmsSymmetric: AES-256, ChaCha20-Poly1305 • Asymmetric: RSA-4096, ECDSA-P384, Ed25519Hashing: SHA-256, SHA-3, BLAKE2 • Key Derivation: PBKDF2, Argon2, scryptDigital Signatures: ECDSA, RSA-PSS • Key Exchange: ECDH, X25519Benefits: Data confidentiality • Integrity protection • Compliance assurance • Trust establishment

Monolithic Architecture

Single deployable unit combining multiple modules. Simple operationally and effective for many products.

single deploysimplicitycohesion
Explore Pattern Details →
Monolithic ArchitectureSingle deployable application with internal modular structure and shared infrastructure.🏢 Monolithic Architecture🔄 Load BalancerTraffic Distribution📦 Single Deployable ApplicationOne codebase, one deployment unit🧩 Business Modules👥 User Module• Authentication• User Management• Profile Service📋 Order Module• Order Processing• Inventory Mgmt• Shipping Logic💳 Payment Module• Payment Processing• Billing & Invoicing• Transaction History🔧 Shared Infrastructure🛡️ Cross-cutting• Security• Logging & Metrics• Caching💾 Data Access Layer• ORM/Entity Framework• Repository Pattern• Data Validation🖥️ Presentation• Web Controllers• API Endpoints• UI Components🗄️ Shared DatabaseSingle database for all modules • ACID transactions⚖️ Horizontal ScalingInstance 2Full App CopyInstance NFull App Copy✅ Benefits• Simple deployment• Easy development• Strong consistency• ACID transactions• Efficient testing• Single codebase• Performance⚠️ Trade-offs• All-or-nothing scale• Technology coupling• Single failure point• Large codebase• Team coordinationBest for: Small-medium teams • Well-understood domains • Performance-critical apps🎯 When to Use• Small to medium teams• Well-understood domain• Rapid prototyping• Simple deployment needs• Performance critical

Additional Architecture Patterns

N‑Tier (Client‑Server) Architecture

Multi-tier runtime architecture (e.g., presentation, application, data) where clients request services from servers across tiers.

n-tierrequest/responsenetworkapi

Microkernel / Plugin Architecture

aka microkernelaka plug-inaka modular architecture

Core system exposes extension points; features are delivered as plugins loaded at runtime or build time.

extensibilitypluginsmodulesextensions

Onion Architecture

aka domain-centric layering

Domain-centric layering with the domain model at the center; infrastructure concerns form outer rings; enforces dependency rule inward.

onionlayersdependency ruledomain

Domain-Centric Architecture

aka onion/hexagonal/clean familyaka DDD-alignedaka domain-centric layering

A family of styles that place the domain model and use cases at the center, enforcing boundaries and dependency inversion.

domainboundariesportsdependency rule

Clean Architecture

aka uncle bobaka screaming architecture

Domain‑centric, dependency‑inversion style family emphasizing concentric layers (entities, use cases, interfaces) and the Dependency Rule.

use casesentitiesdependency rule

CQRS

aka Command Query Responsibility Segregation

Separate write and read models to optimize for different workloads; often paired with events.

readswritesevent sourcingmaterialized views

Serverless

Event-driven functions and managed services with autoscaling and pay-per-use.

faasmanaged servicesscale to zero

Service-Oriented Architecture (SOA)

aka SOA

Reusable, contract-driven services integrated via mediation (often ESBs) with centralized governance; a precursor to microservices.

contractsreusabilitygovernanceESB

Space-Based Architecture

aka in-memory data grid

Scale and resilience via partitioned, replicated in-memory data grids and collocated processing; minimizes database contention.

IMDGgridpartitioningreplication

Data Mesh

Decentralized, domain-oriented data ownership; data as a product with federated governance and platform self-service.

domainsdata productgovernancemesh

Pipes and Filters

Compose sequential processing via independent filters connected by pipes; foundation for ETL, streaming, and reactive pipelines.

ETLstreamingpipelinefilters

Broker (Message‑Brokered)

aka brokeraka message-brokered

Decouple producers and consumers via a broker that routes, buffers, and delivers messages (queues/topics).

brokerqueuetopicpub/sub

Blackboard

Multiple specialized components collaborate by reading/writing to a shared knowledge source (the blackboard) until a solution emerges.

aiknowledge sourcecollaborationcontrol

Understanding Architectural Patterns

🏗️ Structural Patterns

Focus on how components are organized and layered. Examples: Layered, Hexagonal, Clean Architecture.

🚀 Distribution Patterns

Address how to split systems across services and processes. Examples: Microservices, SOA, Event-Driven.

🔐 Security Patterns

Provide proven approaches for securing systems and data. Examples: Zero-Trust, OAuth2, API Security.

📊 Data Patterns

Handle information flow and storage strategies. Examples: CQRS, Event Sourcing, Data Mesh.

Choosing the Right Pattern

  • Consider your context: Team size, domain complexity, and organizational constraints
  • Understand trade-offs: Every pattern comes with benefits and costs
  • Start simple: Begin with proven patterns and evolve as needed
  • Combine patterns: Most real systems use multiple patterns together

Exploration Tips

  • Start with patterns: Choose the architecture that fits your problem first.
  • Then choose blocks: Use pattern↔block relationships to pick enabling capabilities.
  • Search and filter: Focus on the terms that match your constraints.
  • Deep dive: Open pattern pages for diagrams, trade‑offs, and implementation advice.