Mind map

Architecture Styles 2

natalia mejia English

Map content

Event-Driven Architecture Style
- distributed
- asynchronous
- decoupled components
- react to events
- Request-Based
  - request orchestrator
  - synchronously directs requests to processors
- Event-Based Models
  - Reacts to events and takes action accordingly
- Topologies
  - Broker Topology
    - Structure
      - lightweight message broker for distributing events among processors without a central mediator
    - Components
      - Initiating Event
        Starts the event flow
      - Event Broker
        Manages event channels
      - Event Processor
        Handles the event and generates processing events
      - Processing Event
        Advertises the outcome of the event processing
    - Flow
      - 1. The initiating event is sent to the broker.
        2. An event processor handles the event and generates a processing event.
        3. Other processors react to the event and may generate further events.
        4. This continues until the final event processor completes the flow
    - Advantages
      - High decoupling of event processors.
      - Scalability and responsiveness.
      - High performance and fault tolerance.
    - Disadvantages
      - Lack of workflow control.
      - Challenges in error handling and recoverability.
      - No inherent support for restarting or tracking business transactions
  - Mediator Topology
    - Structure
      - Event mediator, which manages and controls the workflow
    - addresses some of the key limitations found in the Broker Topology
    - Components
      - Initiating Event
        The event that starts the entire process
      - Event Queue
        Receives the initiating event
      - Event Mediator
        Manages and controls the workflow of the event
      - Event Channels
        Channels (usually queues) where processing events are sent
      - Event Processors
        Components that handle specific tasks and report back to the mediator
    - Flow
      - 1. Event Initiation: The initiating event is sent to an event queue, which is then picked up by the event mediator.
        2. Event Mediation: The mediator determines the necessary steps for processing the event and generates corresponding processing events. These are sent to dedicated event channels.
        3. Event Processing: Event processors handle tasks as per their specific event channel. They send acknowledgements back to the mediator upon completion.
        4. Workflow Control: The mediator oversees the entire workflow, ensuring each step is completed before moving to the next. It also handles error management and can restart or recover workflows if necessary.
    - Advantages
      - Workflow Control
      - Error Handling
      - Data Consistency
    - Disadvantages
      - Coupling of Event Processors
      - Scalability
      - Performance
      - Complex Workflow Modeling
- Asynchronous Capabilities
  - Allows processes to operate independently of one another
  - Fire-and-Forget
    - The system processes a request without waiting for a response
  - Request/Reply
    - requestor does not wait for an immediate response
  - - Synchronous
    - Asynchronous
  - Trade-offs
    - Responsiveness vs. Performance
    - Error Handling Challenges
      - Without immediate feedback, errors can be difficult to address
- Error Handling
  - Reactive Technique
    - addresses both resiliency and responsiveness
    - Delegation
      - When an error occurs, it is delegated to a workflow processor rather than stopping the entire process
    - Error Analysis and Repair
      - The workflow processor attempts to analyze and repair the error programmatically
    - Resubmission
      - Once errors are handled, corrected messages are resubmitted for processing
  - Benefits
    - Increased Responsiveness
    - Improved Scalability
  - Drawbacks
    - Complex Error Handling
    - Out-of-Sequence Processing
- Preventing Data Loss
  - Potential Scenarios:
    - Message Loss Before Queue
    - Message Loss During Processing:
    - Message Loss During Persistence
  - Techniques to prevent
    - Persistent Message Queues and Synchronous Send
      - Persistent Queues
      - Synchronous Send
    - Client Acknowledge Mode
      - Messages are kept in the queue until the event processor explicitly acknowledges their successful processing
    - ACID Transactions and Last Participant Support (LPS)
      - ACID Transactions
      - Last Participant Support (LPS)
        acknowledging the message only after it has been successfully processed and persisted.
- Broadcasting Events
  - Allows a producer to send a message to multiple subscribers without knowing which subscribers will receive or how they will use the message
  - Benefits
    - Decoupling
    - Eventual Consistency
- Request-Reply Messaging
  - facilitate synchronous communication within an asynchronous system
  - Techniques
    - Correlation ID
      - unique identifier in the message header that links requests and responses
        simplicity and efficiency
        requires message brokers
    - Temporary Queues
      - The producer sends a request with a reference to a temporary queue for the response. The consumer replies to this temporary queue, and then the queue is deleted.
        Simpler to implement
        can impact performance
        overhead of creating and deleting queues
- Characteristics Ratings
Space-Based Architecture Style
- designed to address scalability and performance challenges inherent in traditional web-based architectures
- Traditional Web-Based Architecture Challenges
  - Scalability Issues
  - Complex Scaling
- Solution
  - removes the central database as a synchronous constraint
    - using replicated in-memory data grids
    - asynchronous data processing
  - Benefits
    - High Scalability:
    - Elasticity
    - Concurrency
- Topology
  - Processing Unit
    - Contains application logic and in-memory data grids
  - Virtualized Middleware
    - Manages data synchronization and request handling.
    - Components
      - Messaging Grid
        Manages incoming requests and session states
        Forwards requests to available processing units
        Implementation: Typically uses web servers with load balancing capabilities
      - Data Grid
        Implements replicated in-memory caches
        ensure all processing units have consistent data
        Data synchronization is typically asynchronous and fast
      - Processing Grid
        Optional
        Orchestrates and coordinates requests between different types of processing units
      - Deployment Manager
        Monitors system load
        dynamically manages the startup and shutdown of processing units
        based on current demands
        based on current demands
  - Data Writers
    - update the database with information received from data pumps
    - Changes made in the in-memory data grids of processing units are persisted in the database
    - Types
      - Domain-Based Data Writers
        Handle updates for a specific domain across multiple data pumps and processing units
      - Dedicated Data Writers
        Each data writer is associated with a specific processing unit or data pump.
  - Data Readers
    - Fetch data from the database and load it into the processing units' caches
    - Used when
      - All instances of a processing unit with the same named cache fail or are redeployed
      - Archive data is required that is not available in the replicated cache.
- Characteristics Ratings
- Other considerations
  - Data Collisions
    - When concurrent updates to the same data in different instances result in inconsistencies due to replication latency
    - Factors Influencing Collisions
      - Number of Instances (N)
      - Update Rate (UR)
      - Cache Size (S)
      - Replication Latency (RL
    - CollisionRate = (N×UR^2)/S ×RL
  - Cloud Versus On-Premises
    - Hybrid Model
      - Cloud-Based Processing
      - On-Premises Data Storage:
      - Data Synchronization
  - Replicated vs. Distributed Caching
    - Replicated Caching
      - Use when
        Cache Size: Small
        Data Type: Relatively static
        Update Frequency: Low
        Fault Tolerance: High
    - Distributed Caching
      - use when
        Cache Size: Large
        Data Type: Highly dynamic
        Update Frequency: High
        Fault Tolerance: Low
  - Near-Cache Considerations
    - combining in-memory data grids (front cache) with a distributed cache (full backing cache)
    - hybrid caching model
    - Issues
      - Inconsistency
Orchestration-Driven Service-Oriented Architecture
- Topology
  - Layers
    - Business Services
      - Top-level services representing domain behavior
    - Enterprise Services
      - Fine-grained, reusable services
    - Application Services
      - Single-use services for specific needs
    - Infrastructure Services
      - Operational services
  - Orchestration Engine
    - Central component
    - coordinates interactions between services, manages transactions, and integrates with existing systems.
- Message Flow
  - Centralized
    - All requests go through the orchestration engine
- Challenges and Criticisms
  - High Coupling
    - due to centralized orchestration
    - due to reuse philosophy
  - Granularity
    - Difficulty in determining appropriate transaction boundaries
  - Performance
    - Distributed Nature
    - reliance on a single or few databases
  - Complexity
    - Technical partitioning and the spread of domain concepts across many services can make development and maintenance challenging
- Characteristics
  - - Deployability and Testability
      - high coupling and complexity
    - Elasticity and Scalability
      - scalability was supported through efforts
    - Performance
      - compromised by the architecture’s distributed nature
    - Simplicity and Cost
      - increased both the cost and complexity of maintaining systems
    - Reuse and Coupling
      - high coupling between components
Microservices Architecture
- Topology
- Distributed
  - Separation into Processes
  - Avoidance of Shared Resources
  - Challenges
    - Performance
    - Transactions and Granularity
- Bounded Context
  - Emphasizes decoupling and domain-specific modeling
    - Self-Contained Services
      - Each microservice is designed to operate independently within a specific domain or workflow
    - Avoiding Coupling Through Duplication
      - prioritize avoiding coupling, even if it means duplicating certain components across services.
    - Domain-Partitioned Architecture
      - Each service is tailored to represent a specific domain or subdomain
      - Align closely with the principles of Domain-Driven Design (DDD)
    - Granularity of Services:
      - Guidelines
        Purpose
        Each service should be functionally cohesive
        Transactions
        Avoid distributed transactions
        Choreography
        Combine services into a larger service to reduce overhead
    - Data Isolation
      - Handling Data Distribution
        each service manages its own data
        database replication or caching
      - introduces complexities
- API Layer
  - acts as an intermediary
    - routing
    - load balancing
    - authentication
    - ranslation of requests
  - point of indirection
- Operational Reuse
  - Sidecar Pattern
    - operational consistency
    - sidecar component runs alongside each microservice
    - responsible for handling cross-cutting concerns
    - Benefits
      - Unified Upgrades
      - Standardization
  - challenge is managing operational concerns such as monitoring, logging, and circuit breakers across multiple independent services
  - Service Mesh
    - connects sidecar components into a cohesive operational network
    - Components
      - Service Plane
        consistent interface for operational tasks
      - Console Interface
        allows for global control over the operational environment
- Frontend
  - Monolithic Frontend
    - single user interface interacts with multiple microservices through an API layer
    - Benefits
      - Simplicity
      - Consistent User Experience
    - Challenges
      - Coupling
      - Scalability
  - Microfrontends
    - Each microfrontend is responsible for rendering the UI related to a specific microservice
    - Benefits
      - Independent Deployment
      - Isolation
    - Challenges
      - Complexity
      - Consistency
- Communication
  - Synchronous Communication
    - wait for a response
  - Asynchronous Communication
  - Protocol-aware
    - each service should know how to call other services
  - Heterogeneous
    - microservices fully supports polyglot environment
  - Interoperability
    - services calling one another
- Choreography and Orchestration
  - Choreography
    - services interact directly with each other
    - Decoupled Events
      - Each service emits and listens to events, reacting to changes and data from other services as needed
    - Benefits
      - Decoupling
      - Flexibility
    - Challenges
      - Complex Error Handling
      - Increased Complexity in Services
  - Orchestration
    - central coordinator
    - controls the sequence of interactions between services
    - Centralized Control
    - Benefits
      - Better Error Handling
      - Simplified Service Logic
    - Challenges
      - Coupling
      - Single Point of Failure
- Transactions and Sagas
  - managing transactions maintaining decoupling
  - Challenges
    - Decoupling
      - Each service often has its own database, difficult to maintain transactions
    - Service Granularity
      - need for cross-service transactions
  - The Saga Pattern
    - Saga is a sequence of local transactions
      - each step in the process has a compensating action to undo the previous steps if something goes wrong
    - Tradeoff
      - Increased Complexity
      - Network Traffic
      - Performance Impact
    - Components
      - Coordinator (Mediator)
        A service or component
      - Success Flow
        coordinator calls each service in the transaction sequence
        all the services complete their tasks successfully
        transaction complete
      - Compensation Flow
        any service in the sequence fails
        coordinator triggers compensating transactions, for each previously successful step
        rolling back the overall transaction to maintain consistency
- Characteristics Ratings