2022-02-20 Chapter 14 - Decoupling Workflows

service-sqs-001; Tightly coupling applications, such as having an EC2 instance talk directly to another EC2 instance, is a{{c1::n antipattern}}. Always {{c1::loosely}} couple applications!

service-sqs-002; {{c1::Simple Queue Service (SQS)}} is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems and serverless applications.

service-sqs-003; Simple Queue Service (SQS) is a poll-based messaging queue that allows {{c1::asynchronous}} processing of work i.e. one resource can write a message to an SQS queue, then another resource can retrieve that message from SQS.

service-sqs-004; SQS allows users to configure a {{c1::delivery delay}} parameter. The default value is {{c1::0}} and it can be set up to {{c1::15}} minutes. A non-zero {{c1::delivery delay}} value will hide new messages from the queue for the duration of the delay.

service-sqs-005; SQS allows users to configure a message size up to a maximum of {{c1::256 KB}} of text in any format.

service-sqs-006; SQS messages are encrypted in transit by default. Users can optionally add {{c1::at-rest encryption}}.

service-sqs-007; SQS messages are retained in the queue by default for {{c1::4 days}}. Retention can be set between 1 minute and {{c1::14 days}}.

service-sqs-008; SQS offer either long or short polling. {{c1::Short polling}} is the default. Short polling uses many short connections to check SQS for messages, while long polling uses long connections and is often preferable to short polling. Short polling can use CPU unnecessarily.

service-sqs-009; SQS queue depth can be a trigger for {{c1::autoscaling}} EC2 instances elsewhere in your application.

service-sqs-010; SQS has a configurable {{c1::visibility timeout}} parameter. The default value is {{c1::30}} seconds. This locks a message for other readers once a client starts to read it. This helps to ensure that messages are processed {{c1::only once}}.

service-sqs-011; Messages are {{c1::deleted from SQS}} once a client successfully processes them.

service-sqs-012; SQS offers a {{c1::dead-letter queue}} feature in which problematic messages can be are sidelined. A {{c1::dead-letter queue}} is simply a separate SQS queue which is linked to a primary queue.

service-sqs-013; SQS queues allow users to configure a {{c1::maximum receives}} parameter between {{c1::1}} and {{c1::1000}}. This is the number of times that a client can attempt to process a message before it is considered unsuccessful and sent to an associated dead-letter queue.

service-sqs-013; It's important to set up {{c1::CloudWatch alarms}} to monitor queue depth in primary SQS queues and also in dead-letter queues.

service-sqs-014; SQS offers two types of queue which vary in terms of how they handle message ordering and duplication: 1) {{c1::standard queue}} which guarantees at least once delivery and best effort ordering and offers nearly unlimited transactions per second 2) {{c1::FIFO queue}} which guarantees exactly once delivery and first-in-first-out ordering and offers 300 messages per second.

service-sqs-015; SQS FIFO queues are more {{c1::expensive}} than standard queues.

service-sqs-016; SQS FIFO queues have a message group ID parameter which ensures that messages are processed {{c1::one by one}}. Deduplication only happens within distinct message groups.

service-sqs-017; SQS FIFO queues have a message deduplication ID parameter which is used to deduplicate messages received during a given window ({{c1::5}} minutes).

service-sqs-018; SQS queues are not bi{{c1::directional}}. Bidirectional messaging would require {{c1::two queues}}.

service-sns-001; {{c1::Simple Notification Service (SNS)}} is a fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication.

service-sns-002; Simple Notification Service (SNS) is a push-based messaging service which proactively delivers messages to the endpoints subscribed to it. It can be used to alert a {{c1::system}} or {{c1::person}}.

service-sns-003; A subscriber to an SNS topic can be Kinesis Data Firehose, SQS, Lambda, email, HTTP(S), SMS or others. A topic can have {{c1::multiple}} subscribers.

service-sns-004; SNS allows users to configure a message size up to a maximum of {{c1::256 KB}} of text in any format.

service-sns-005; SNS topics can send failed messages to {{c1::SQS DLQs}}.

service-sns-006; SNS offers FIFO or Standard. FIFO only supports {{c1::SQS}} as a subscriber.

service-sns-007; SNS topics are encrypted in transit by default. Users can optionally add {{c1::at-rest encryption}}.

service-sns-008; A {{c1::resource policy}} can be added to an SNS topic to control access, similar to in S3.

service-sns-009; SNS topics only support retries for {{c1::HTTP(S) subscribers}} and not other types of subscribers.

service-sns-010; SNS can be used to transmit notifications from {{c1::CloudWatch}} alarms.

service-apigateway-001; {{c1::API Gateway}} is a fully managed service that makes it easy for developers to create, publish, maintain, monitor and secure APIs at any scale.

service-apigateway-002; API Gateway allows you to easily protect your endpoints by attaching a {{c1::web application firewall (WAF)}}.

service-apigateway-003; API Gateway can stop abuse by implementing {{c1::DDoS protection}} and {{c1::rate limiting}}.

service-apigateway-004; API Gateway supports API {{c1::versioning}}.

service-apigateway-005; Using API Gateway allows you to avoid {{c1::baking credentials}} into your code.