A
B
C
D
E
100
  • Description: Separates the system into two parts: the A-side (user interface, input handling) and the sB-side (data processing, storage, and management).
  • Use Cases: Web applications, distributed systems, network applications.
  • Advantages: Scalability, separation of concerns, centralized data management.
  • Disadvantages: Single point of failure, network dependency, potential performance bottlenecks.

Client-Server Pattern

100
  • Description: Components in the system communicate by producing and consuming events, allowing for loose coupling and asynchronous communication.
  • Use Cases: User interface design, real-time systems, IoT applications.
  • Advantages: Loose coupling, scalability, responsiveness, parallel processing.
  • Disadvantages: Complexity, potential for race conditions, debugging challenges.

Event-Driven Pattern

100
  • Description: Separates the system into a small, lightweight kernel and a set of pluggable components or services that communicate through well-defined interfaces.
  • Use Cases: Operating systems, embedded systems, modular software architectures.
  • Advantages: Extensibility, maintainability, fault isolation, portability.
  • Disadvantages: Increased complexity, potential performance overhead, coupling between components.

Microkernel Pattern

100
  • Description: Breaks down a monolithic application into a set of small, independent, and loosely coupled services that communicate through lightweight protocols.
  • Use Cases: Cloud-native applications, scalable and distributed systems.
  • Advantages: Scalability, resilience, independent deployment, technology diversity.
  • Disadvantages: Increased complexity, distributed system challenges, potential for data consistency issues.

Microservices Pattern

100
  • Description: Introduces a centralized component (the broker) that mediates communication between decoupled components or services.
  • Use Cases: Message queueing, publish-subscribe systems, enterprise integration.
  • Advantages: Decoupling, scalability, reliability, load balancing.
  • Disadvantages: Increased complexity, potential single point of failure, potential performance bottlenecks.

Broker Pattern

200
  • Description: A variation of the Broker Pattern, where components communicate through an event bus by publishing and subscribing to events.
  • Use Cases: Event-driven architectures, reactive programming, distributed systems.
  • Advantages: Loose coupling, scalability, responsiveness, parallel processing.
  • Disadvantages: Complexity, potential for race conditions, debugging challenges, potential performance bottlenecks.

Event-Bus Pattern

200
  • Description: Structures the system as a sequence of processing components (filters) connected by channels (pipes), where the output of one filter is the input to the next.
  • Use Cases: Data processing pipelines, batch processing, stream processing.
  • Advantages: Reusability, modularity, parallelism, testability.
  • Disadvantages: Potential for performance bottlenecks, limited flexibility, potential for data consistency issues.

Pipe-Filter Pattern

200
  • Description: Separates the problem-solving logic from the data and control flow, allowing multiple independent components (knowledge sources) to collaborate on solving a problem by updating a shared data structure (the blackboard).
  • Use Cases: AI systems, expert systems, complex problem-solving.
  • Advantages: Modularity, flexibility, separation of concerns.
  • Disadvantages: Increased complexity, potential for data consistency issues, potential performance bottlenecks.

Blackboard Pattern

200
  • Description: Structures the system as a collection of loosely coupled, reusable services that communicate through well-defined interfaces and protocols.
  • Use Cases: Enterprise applications, distributed systems, integration of heterogeneous systems.
  • Advantages: Reusability, scalability, flexibility, loose coupling.
  • Disadvantages: Increased complexity, potential performance overhead, potential for versioning issues.

Service-Oriented Architecture (SOA)

200
  • Description: A traditional architectural style where the entire application is built as a single, tightly coupled unit, with all components and functionality contained within a single codebase and executable.
  • Use Cases: Small to medium-sized applications, legacy systems, simple use cases.
  • Advantages: Simplicity, ease of development, ease of deployment.
  • Disadvantages: Scalability limitations, lack of flexibility, difficult to maintain and update.

Monolithic Architecture

300
  • Description: Components in the system communicate by sharing data in a common, virtual space, rather than directly interacting with each other.
  • Use Cases: Distributed systems, parallel computing, data-intensive applications.
  • Advantages: Decoupling, scalability, fault tolerance, parallel processing.
  • Disadvantages: Increased complexity, potential for data consistency issues, potential performance bottlenecks.

Space-Based Architecture

300
  • Description: A decentralized architecture where nodes (peers) in the network act as both clients and servers, sharing resources and workloads among themselves.
  • Use Cases: File-sharing networks, blockchain systems, distributed computing.
  • Advantages: Decentralization, scalability, fault tolerance, resource sharing.
  • Disadvantages: Lack of centralized control, potential security vulnerabilities, potential for free-rider issues.

Peer-to-Peer Architecture

300
  • Description: A pattern where separate backend services are created for different types of client applications (e.g., mobile, web, IoT), each tailored to the specific needs of that client.
  • Use Cases: Multi-client applications, mobile apps, IoT devices.
  • Advantages: Tailored APIs, scalability, separation of concerns.
  • Disadvantages: Increased complexity, potential for duplication.

Backends for Frontends

300
  • Description: A pattern that isolates critical resources (like network connections or database connections) into pools, preventing failures in one part of the system from cascading to others.
  • Use Cases: Fault tolerance, resilience, resource management.
  • Advantages: Fault isolation, resilience, resource management.
  • Disadvantages: Increased complexity, potential for resource underutilization.

Bulkhead

300
  • Description: A pattern where data is cached in a separate data store (e.g., Redis, Memcached) to improve performance and reduce the load on the primary data store.
  • Use Cases: Improving performance, scalability, read-heavy workloads.
  • Advantages: Improved performance, scalability, offloading primary data store.
  • Disadvantages: Increased complexity, potential for data inconsistency.

Cache-Aside

400
  • Description: A pattern where two or more services collaborate to complete a task, without a centralized controller, by exchanging messages and events.
  • Use Cases: Microservices architectures, event-driven architectures.
  • Advantages: Decoupling, scalability, fault tolerance.
  • Disadvantages: Increased complexity, potential for data inconsistency.

Choreography

400
  • Description: A pattern where each deployment of a service or application is given a unique stamp or identifier, allowing for rolling deployments, rollbacks, and separating different versions of the same service.
  • Use Cases: Continuous deployment, rolling updates, blue-green deployments.
  • Advantages: Rollback capabilities, safe deployments, version control.
  • Disadvantages: Increased complexity, potential for versioning issues.

Deployment Stamps

400
  • Description: A pattern where a service acts as a gatekeeper, enforcing security policies, authentication, and authorization for accessing other services or resources.
  • Use Cases: Security, access control, microservices architectures.
  • Advantages: Centralized security enforcement, separation of concerns, scalability.
  • Disadvantages: Potential single point of failure, increased complexity.

Gatekeeper

400
  • Description: A pattern where a gateway service consolidates multiple requests into a single request to a backend service, aggregating the responses and returning them to the client.
  • Use Cases: Microservices

Gateway Aggregation

400
  • Description: A pattern where a pre-computed view or summary of data is stored and maintained, allowing for faster query performance and reducing the load on the primary data store.
  • Use Cases: Data warehousing, reporting, analytics, caching.
  • Advantages: Improved query performance, reduced load on primary data store.
  • Disadvantages: Increased storage requirements, potential for data inconsistency.

Materialized View

500
  • Description: A pattern where senders (publishers) send messages to a messaging system, and receivers (subscribers) receive only the messages they are interested in, based on subscriptions or topics.
  • Use Cases: Event-driven architectures, message distribution, decoupling.
  • Advantages: Loose coupling, scalability, flexibility.
  • Disadvantages: Increased complexity, potential for message ordering issues.

Publisher/Subscriber

500
  • Description: A pattern for managing data consistency across microservices by breaking down a transaction into a sequence of local transactions, with compensation actions for failed transactions.
  • Use Cases: Distributed transactions, microservices architectures, event-driven architectures.
  • Advantages: Data consistency, fault tolerance, scalability.
  • Disadvantages: Increased complexity, potential for data inconsistency, potential for performance overhead.

Saga

500
  • Description: A pattern where a scheduler component assigns tasks to a pool of worker agents, and a supervisor component monitors the agents and handles failures or reassigns tasks if necessary.
  • Use Cases: Task scheduling, distributed systems, fault tolerance.
  • Advantages: Fault tolerance, scalability, load balancing.
  • Disadvantages: Increased complexity, potential for single point of failure.

Scheduler Agent Supervisor

500
  • Description: A pattern where a large dataset or database is partitioned into smaller, more manageable shards, with each shard residing on a separate server or node.
  • Use Cases: Scalability, performance optimization, distributed systems.
  • Advantages: Scalability, improved performance, parallel processing.
  • Disadvantages: Increased complexity, potential for data inconsistency, potential for load imbalance.

Sharding

500
  • Description: A pattern where static content (e.g., images, CSS, JavaScript files) is hosted and served separately from the application server, typically through a content delivery network (CDN) or a dedicated static content server.
  • Use Cases: Web applications, content delivery, performance optimization.
  • Advantages: Improved performance, scalability, offloading application servers.
  • Disadvantages: Increased complexity, potential for caching issues.

Static Content Hosting