Fawry cloud devops internship
  • Application production deployment architecture
  • Application Deployment Process
  • Application Deployment pricing
  • Kubernetes ConfigMap and Secret
  • Kubernetes Network
  • Kubernetes PV & PVC
  • kubernetea Labs
  • Kubernetes Session 3
  • Kubernetes Session 2
  • Kubernetes Architecture
  • Amazon SQS
  • AWS SNS
  • AWS Elastic Transcode
  • AWS RDS
  • Amazon Aurora RDS
  • Amazon RDS for Oracle
  • Amazon RDS for PostgreSQL
  • Amazon RDS for MySQL
  • Amazon RDS for SQL Server
  • Amazon RDS Multi-AZ with one standby
  • AWS RDS Automated Backup
  • Amazon RDS - Event Notifications
  • Amazon RDS - DB Access Control
  • Amazon RDS - Data Import / Export
  • Amazon RDS - DB Monitoring
  • Amazon RDS on VMware
  • Amazon Aurora Serverless
  • Cloud Computing
  • AWS
  • AWS Features
  • AWS Global Infrastructure
  • AWS Services
  • AWS IAM
  • AWS S3
  • AWS S3 Lifecycle Management
  • EC2
  • Instance types
  • AMI
  • EBS
  • Elastic File System
  • EC2 Lab with EFS shared
  • AWS Route53
  • AWS VPC
  • EC2 placement group
  • AWS LB
  • EC2 Auto Scaling
  • Cloud Watch
  • SeMA Deployment Architecture
    • SeMA application sizing-estimation process .
    • SeMA Deployment Architecture
  • Laravel Deployment Architecture
    • Larvel application sizing-estimation process .
    • SeMA Deployment Architecture
  • SeMA Survey Application Deployment Architecture
  • Fawry DevOps internship Agenda
  • Fawry cloud devops internship
  • User Guide
  • FAQ
  • Application Architecture
    • Architecture
    • UI : Angular 8
    • Web : PHP Laravel
    • Analytics : Metabase
    • DB : MariaDB
    • Application Security Course
  • ZiSoft Deployment
    • Non-Production Deployment
    • Kubernetes Production Deployment
    • Offline Production Deployment
    • SaaS :Kubeapps
  • Linux for DevOps
  • Architecture of Linux system
  • Linux Directory Structure
  • Linux Commands
  • Linux labs
  • Docs
  • GIT
  • Git vs SVN
  • Git Flow / Git Branching Model
  • Git Version Control System
  • Git Terminology
  • Git Commands
  • Git Remote
  • Git Stash
  • Git Merge and Merge Conflict
  • Merge vs Rebase
  • Git Tags
  • Containerization
  • Dockerfile
  • Docker Compose
  • Docker Architecture
  • DevOps part 1 : interview
Powered by GitBook

Amazon SQS

Last updated 1 year ago

Was this helpful?

Distributed queues

There are three main parts in a distributed messaging system: the components of your distributed system, your queue (distributed on Amazon SQS servers), and the messages in the queue.

In the following scenario, your system has several producers (components that send messages to the queue) and consumers (components that receive messages from the queue). The queue (which holds messages A through E) redundantly stores the messages across multiple Amazon SQS servers.

Message lifecycle

The following scenario describes the lifecycle of an Amazon SQS message in a queue, from creation to deletion.

Standard queues
FIFO queues

Unlimited Throughput – Standard queues support a nearly unlimited number of API calls per second, per API action (SendMessage, ReceiveMessage, or DeleteMessage).

At-Least-Once Delivery – A message is delivered at least once, but occasionally more than one copy of a message is delivered.

Best-Effort Ordering – Occasionally, messages are delivered in an order different from which they were sent.

Exactly-Once Processing – A message is delivered once and remains available until a consumer processes and deletes it. Duplicates aren't introduced into the queue.

First-In-First-Out Delivery – The order in which messages are sent and received is strictly preserved.

Send data between applications when the throughput is important, for example:

  • Decouple live user requests from intensive background work: let users upload media while resizing or encoding it.

  • Allocate tasks to multiple worker nodes: process a high number of credit card validation requests.

  • Batch messages for future processing: schedule multiple entries to be added to a database.

Send data between applications when the order of events is important, for example:

  • Make sure that user-entered commands are run in the right order.

  • Display the correct product price by sending price modifications in the right order.

  • Prevent a student from enrolling in a course before registering for an account.

A producer (component 1) sends message A to a queue, and the message is distributed across the Amazon SQS servers redundantly.

When a consumer (component 2) is ready to process messages, it consumes messages from the queue, and message A is returned. While message A is being processed, it remains in the queue and isn't returned to subsequent receive requests for the duration of the .

The consumer (component 2) deletes message A from the queue to prevent the message from being received and processed again when the visibility timeout expires.

Amazon SQS supports two types of queues – standard queues and FIFO queues. Use the information from the following table to chose the right queue for your situation. To learn more about Amazon SQS queues, see and .

High Throughput – If you use , FIFO queues support up to 3,000 calls per second, per API method (SendMessageBatch, ReceiveMessage, or DeleteMessageBatch). The 3,000 calls per second represent 300 API calls, each with a batch of 10 messages. To request a quota increase, . Without batching, FIFO queues support up to 300 API calls per second, per API method (SendMessage, ReceiveMessage, or DeleteMessage).

Amazon SQS Standard queues
Amazon SQS FIFO (First-In-First-Out) queues
batching
submit a support request
visibility timeout