Know about topics and queues.

With a queue, you can have multiple consumers of a queue and each message will be delivered once; if there are no consumers when the message arrives, it sits in the queue until a consumer arrives.

With a topic you can have multiple consumers and each message will be delivered once to each consumer, but if a consumer is offline when a message arrives they miss it.

• SNS is not a queuing system. It’s a notifications system that can generate email, SMS, HTTP calls, etc. You can subscribe lambdas to SNS topics but SNS is not a queueing service.

• Amazon MQ is hosted Apache Active MQ, which is AMQP 1.0. If you were developing an asynchronous service from scratch, this would be your most portable option.

• SQS is Amazon’s own queueing service, which has a lot of pitfalls like visibility timeouts, non-FIFO queues by default, no guarantees against duplicates, different polling mechanisms, etc.

• This architecture comprises multiple decoupled micro services

• Events refer to a change in state or update

• Events trigger communication between services

• Events can carry the state or act as messengers as notifications

• Event Producers

• Event Routers

• Event Consumers

Event producer apps and consumer apps are decoupled, this enables the apps to independently deployed, update, scale.

• Independent scale and fail - no single point of failure
• As it is support decoupled architecture, apps/services can be built in varieties of tech stack in contrast with monolith arch

• Understand the resiliency, scaling aspects to accommodate the demand
• Objective is to build resiliency into workloads
• How do we Build resiliency in our applications
  • Evaluate scaling resources available to accommodate customer demand
  • Goal is to build resiliency in the application itself to handle the workloads, failures

The system should be designed and built to identify the failures and self heal

• Managing Failures

  • Transaction Failure - happens when a component is not available due to heavy load
  • Partial Failure - happens when a batch processing being performed (increases load on resources, hence resource unavailable to serve)
  • Intermittent Failure - happens when network failure

• How do we deal with failures?

  • Retry until succeed
  • Improves reliability
  • Reduces operational cost

• Backoff: A better approach by enabling clients wait before retries

  • As retrying is not always effective, when a system is already failing due to overload, then the retries will increase the system load
  • Exponential backoff is most common approach to make clients wait for larger intervals exponentially before the retry
  • Maximum delays and no.of retries are normally configured in this approach

• Jitter - when Backoff is not enough

  • In backoff approach, when multiple retries from all backoff systems simultaneously, there is a chance that requests will burst into the system, this will overburden the system, Jitter system modifies the timings of retries by adding some randomness (delaying requests) to the timing of backoff
  • This can be used to reduce the impact of huge burst into the system

• Dealing with Failed Messages (message queue) - below options provide ways to handle messages cannot be processed successfully by a system

  • Failures Destinations - is an alternate destination for messages that could not be processed, separate event destinations can be configured for failure messages
  • Dead-letter queues (DLQ) - It is a specific failure destination to store the messages that cannot be processed by a system due to an error or lack of resources, these messages can be inspected and either retried or discarded.

• AWS Step Functions - Orchestrating long-running transactions - Where series of transaction steps can be configured with error handling and retry capabilities
  • Distributed Transactions - AWS step functions help focusing on business logic instead of orchestration logic

Essential for component to component communication in a serverless event-driven application

• Event indicates that something in the environment is changed, most of services in aws (cloudformation, ec2, etc) generates events
• It is a pipeline for receiving events
• Events that are coming to event bridge, are linked to a single event bus only, where the events are evaluated based on rules defined with the event bus, which means the rules are applied to events on the event bus it associated with.
• Uses Resource-based policy to manage permissions for event bus
• Maximum of 300 rules can be configured per event bus
• Custom event bus can also be created for custom applications, also applies with max 300 rules to be configured.

A Rule matches incoming events and sends events to one or more targets to process

• Multiple targets run in parallel
  • Example target: A lambda function, SNS Topic, SQS Queue etc

• Indicates something is changed in the system (ex: ec2 scale out/in, clouformation etc)
• Scheduled Events
• Events are represented as Objects in JSON Format

• Target is a Resource or endpoint to route the events to
• Permission is required to send the data to the target resource and access the target resource
• Maximum 5 targets per rule can be created
• Delay with new targets, brief delay should be given propagate the changes to new targets

It is an event structure definition for the event

• It is a managed service for delivering messages in Pub-Sub Model, aka Producers and Consumers Model
• Publisher asynchronously sends a message to a topic, Subscribers Subscribes to the topic to receive the message
  • Topic is simple communication channel
• Subscriber receives messages via one of the supported "Endpoint" (ex: SQS, push notification, mail)

• Enables app-to-app messaging (to talk to each other) in distributed microservice architecture
• Allows to persist the messages in SQS to enable the applications to process them later
• Used for App-to-Person Notifications (ex: SMS to one or more users)
• Supports Standard and FIFO topics (when there is need for strict ordering of sending messages, use this First In First Out type)
• Supports Message Durable (messages are stored in geographically distributed servers)
• SNS preserves any messages that are not delivered in the dead letter queue, before the retry policy expire
• Supports Message Archiving and analytics feature - to analyse the message

• Compatible with SQS
  • Under the hood, SNS subscribes to a standard SQS Queue to a SNS Topic
  • If order matters, Only SQS FIFO queue can subscribe to SNS FIFO Topic
• Compatible with AWS Lambda
• Compatible with IAM - to control who and what can be allowed to use
• Compatible with AWS CloudFormation on the automation

• App Integration to Fan Out to push out the messages to multiple endpoints - to SQS Queues, Lambda functions, Https endpoints etc
  • Fan out is an asynchronous parallel processing
• App alerts
• User app Notifications, mobile push notifications - direct notifications

• Access the service

• Message destination

• Event notification source

• Configuring Features

• Messages

  • Filtering policy (subset of messages)
  • Delivered immediately once they published
  • If not delivered for some reason, it goes into retry policy
  • Archiving messages and anlytics

• Message Ordering and Deduplication

  • Ensures the sequence of messages and No duplicates

• This is essential for application requires near real time data consistency

• Limitations

  • FIFO Topics supports only 300 Messages per topic or 10MBs per second per topic, It also supports Filtering messages, Subscribers can have filter policy to receive a subset of messages, this can be added as subscription attributes
  • Standard Topics supports unlimited no.of messages per second

• Avoiding Message Duplications

  • If a message deduplication id is published within 5 mins interval, the message is accepted but not delivered

• Security

  • Encryption for messages
  • Secure Connection between the client and VPC
  • Durable - by storing in multiple data center across geography or availability zones
  • Implementing DLQ if messages not delivered before retry policy expire

• Raw Message Delivery (SNS, Http, HTTPS), these services doesnt have to validate the message body as it is in strict format already

  • Supports upto 10 attribute items
  • each attribute has a name and data type - binary, string, string[], number
  • and value must not be empty or null

• There are reserved message attributes used for mobile push notifications

• Message attributes are useful when need of message filtering policy to be applied

• Supports topics with cross (different) account subscriptions

• Supports cross region delivery

• Maximum size of message is 256Kb
• Leverage Amazon SNS Extended Client for java library to send larger than 256kbs messages to sns queue, max upto 2Gb per message
  • In this case, the library stores the large message payload in s3 bucket and pass only the reference of the object to the topic

• SNS supports sending messages to different regions
• It supports message delivery status
• It Supports message delivery retries, when there are server side issues
  • SNS discards the messages after the delivery retry policy expired, unless there is a dead letter queue attached to it.
• Dead-letter queue - place where undelivered messages are stored for further analysis and processing

• Allows us to build and run workflows in cloud, it is also known as server-less orchestration service
• This workflow is called as State Machine includes collection of steps that can invoke lambda fns or other services
• It coordinates multiple event driven steps in a work flows, step fns automatically take care of error handling, retries and parallel processing
• It also provides visual representations of the workflow, easier to understand troubleshoot

• Can be useful to define workflow for user onboarding in a company to perform series of steps in an order
• Useful in performing ETL jobs
• IT security automation, service management operations to avoid the human interventions

• Workflows are set of activities to perform some objectives
• Helps to build distributed asynchronous applications workflow
• Each workflow runs in a domain, that domain controls the scope for the workflow, cross domain interaction of workflow not possible
• Tasks are logical unit of work
• It can run on cloud or on-premises
• Activity Task, Decision Task, Lambda Task
• Workflows are stateless
• Workflow history is a complete information of the workflow execution, input/output, results of execution

• It is managed message broker service
• Facilitates the communication between apps and components
• Any org uses RabbitMQ and Apache ActiveMQ can migrate into Amazon MQ without rewriting the code, MQ supports both engine
• Amazon MQ is based on Apache ActiveMQ engine (java based message broker)
• Each Amazon MQ Broker runs on Ec2 instance

• Unlimited messages per second