Cloud Computing Software Architecture patterns

Cloud Computing Software Architecture patterns

1. Scalability Patterns

   • Load balancing
     • Round Robin - stateless
     • Sticky Session - statefull
     • Least Connections
   • Pipes and Filters
     • Allow use the right resources/stack for each task
     • stateless
     • No for transacctions where atomicity and data consistency are important
   • Scatter Gather
     • Use case: Search Services  Hospitality services  Separe dischert to aggegator when execution time is too longexecute in paralle the search and at the end the dispatcher agregate the response
     • Dispatcher
       • Workers
     • time out for response
     • Use message broker to decoupling
     • Separete in Dispatcher and Aggregator
     • Unique request id
   • Orchestrator Pattern For Microservices
     • Similar to scatter Gatter but here usually the task are in sequencial, it could has task in paralell too. No business logic If there are a few team and each team need to modify it services, and also need to modify the orchestrator then there is a dependency between their and need to coordinate well their changes on Orchestrator
     • No business logic
     • Usually in sequential
     • Exception and retry
     • Database State for transaction
     • Not decoupling for modification
   • Choreography Pattern
     • In this pattern there is not a orchestrator , instead we use a message queue or message broker and each service subscribe on it interest topic
     • Communication is Asynchronous
       • Easy add/remove services
       • Easy make changes over the system
     • Scale any flow to many services
     • Scale our organization easily
       • many teams
       • little friction

2. Performance Paterns for Data Intensive Systems

   • Map Reduce
     • MaP
       • This process calculate a function or logic for a frction of date and generate a new intermediate key/pairs
     • Reduce
       • Take the intermedia key/pairs and execute the reduce function over intermediate key/pairs and generate a result with aggregated values
     • Batch Processing model
     • Big data
   • Saga
     • Resumen de EstrategiasIdempotencia: Repetición segura de operaciones sin efectos colaterales.Reintentos con backoff: Minimizar cargas innecesarias y mejorar la probabilidad de éxito.Monitoreo y alertas: Detección proactiva de fallos y notificaciones para intervención humana.Persistencia de estado: Mantener el estado de la Saga para continuar en caso de fallo.Circuit Breaker: Aislar fallos recurrentes.Aislamiento temporal: Evitar que datos inconsistentes sean visibles antes de la compensación.Compensaciones simples: Menor complejidad para mayor fiabilidad.Intervención manual: Asistencia humana cuando las operaciones automáticas fallan.Compensación retrasada: Dar tiempo adicional antes de realizar la compensación.Verificación de consistencia: Detectar y corregir inconsistencias antes de que escalen.
     • Distributed transactions
     • Compensation
     • Could be implemented using orchestation or coreografy
   • Transactional Outbox Pattern
     • This pattern try to fix the possible issue present when a service try to do something in the DB and next send a message to a message broker.  Because this operations can not be atomic.
     • Message relay service
     • Business service
       • Normal table
       • Outbox table with sequence, message is and state
         • Each update to a busines logic goes to the outvox table as part of a transaction
   • Materialized view Pattern
     • Tables
     • Views
       • Scheduled update
       • automatic update
       • Same DB
       • In memory DB
     • Trade offs
       • Additional Space for performance
       • Cost for high performance