Architecture Styles 2

Architecture Styles 2

1. 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

2. 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

3. 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

4. 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

Bilder und Dateien der Mindmap