Need advice about which tool to choose?Ask the StackShare community!

Amazon SQS

2.2K
2K
+ 1
171
Redis

57.9K
44.6K
+ 1
3.9K
Add tool

Amazon SQS vs Redis: What are the differences?

Amazon Simple Queue Service (SQS) and Redis are messaging and queuing solutions designed to enhance the scalability and reliability of distributed systems. Let's explore the key differences between the two:

  1. Scalability: The key difference between Amazon SQS and Redis is their approach to scalability. Amazon SQS is a fully managed message queuing service that automatically scales based on the number of messages in the queue. It can handle high traffic and deliver messages reliably, making it suitable for applications with unpredictable workloads. On the other hand, Redis is an in-memory key-value store that can also be used as a message broker. It offers high performance and can handle large amounts of data, making it ideal for use cases that require real-time processing and caching.

  2. Message Persistence: Another major difference is how Amazon SQS and Redis handle message persistence. Amazon SQS stores messages in queues, ensuring durability and persistence even in the event of failures. Messages can be retained in the queue for up to 14 days, providing a reliable messaging system. Redis, on the other hand, is an in-memory database where messages are stored in memory for faster access. While Redis offers persistence options like snapshotting and replication, it primarily relies on memory for performance, making it more suitable for scenarios where message durability is not the primary concern.

  3. Message Ordering: When it comes to message ordering, there is a difference between Amazon SQS and Redis. Amazon SQS guarantees the order of the messages within a single queue, ensuring that they are processed in the order they are received. This makes it suitable for applications where message ordering is crucial, such as task queues or job processing. Redis, on the other hand, does not guarantee message ordering. It offers the flexibility to prioritize messages based on priorities or timestamps, allowing for more specific use cases but sacrificing strict ordering guarantees.

  4. Data Structure Support: Amazon SQS and Redis support different data structures. Amazon SQS primarily handles messages in the form of strings, allowing for flexible message content. Redis, on the other hand, is known for its support of various data structures like strings, hashes, lists, sets, and more. This makes Redis a versatile choice when it comes to storing and manipulating complex data structures, providing additional functionality beyond basic message queuing capabilities.

  5. Pub/Sub Support: Amazon SQS and Redis differ in their support for publish/subscribe (pub/sub) messaging patterns. Amazon SQS focuses on point-to-point messaging, where messages are sent to specific queues and consumed by specific subscribers. Redis, on the other hand, natively supports pub/sub messaging, allowing messages to be published to channels and consumed by multiple subscribers. This makes Redis a suitable choice for real-time messaging scenarios, where multiple components or clients need to receive messages simultaneously.

  6. Managed vs Self-hosted: Lastly, the difference between Amazon SQS and Redis lies in their management. Amazon SQS is a fully managed service provided by Amazon Web Services (AWS), taking care of the infrastructure, scaling, and maintenance. It offers a serverless experience, making it easy to use and suitable for applications that prefer a hands-off approach to managing messaging. Redis, on the other hand, is an open-source software that can be self-hosted or managed through third-party services. While it offers more control and customization options, it requires more effort in terms of deployment, maintenance, and scaling.

In summary, Amazon SQS excels in simplicity and seamless integration within the AWS environment, making it suitable for various distributed applications. On the other hand, Redis stands out for its multifaceted use cases, serving as both a high-performance message broker and a powerful in-memory database, making it a compelling choice for scenarios where caching and persistent storage needs coalesce with messaging requirements.

Advice on Amazon SQS and Redis
Pulkit Sapra
Needs advice
on
Amazon SQSAmazon SQSKubernetesKubernetes
and
RabbitMQRabbitMQ

Hi! I am creating a scraping system in Django, which involves long running tasks between 1 minute & 1 Day. As I am new to Message Brokers and Task Queues, I need advice on which architecture to use for my system. ( Amazon SQS, RabbitMQ, or Celery). The system should be autoscalable using Kubernetes(K8) based on the number of pending tasks in the queue.

See more
Replies (1)
Anis Zehani
Recommends
on
KafkaKafka

Hello, i highly recommend Apache Kafka, to me it's the best. You can deploy it in cluster mode inside K8S, thus you can have a Highly available system (also auto scalable).

Good luck

See more
Meili Triantafyllidi
Software engineer at Digital Science · | 6 upvotes · 432.2K views
Needs advice
on
Amazon SQSAmazon SQSRabbitMQRabbitMQ
and
ZeroMQZeroMQ

Hi, we are in a ZMQ set up in a push/pull pattern, and we currently start to have more traffic and cases that the service is unavailable or stuck. We want to: * Not loose messages in services outages * Safely restart service without losing messages (ZeroMQ seems to need to close the socket in the receiver before restart manually)

Do you have experience with this setup with ZeroMQ? Would you suggest RabbitMQ or Amazon SQS (we are in AWS setup) instead? Something else?

Thank you for your time

See more
Replies (2)
Shishir Pandey
Recommends
on
RabbitMQRabbitMQ

ZeroMQ is fast but you need to build build reliability yourself. There are a number of patterns described in the zeromq guide. I have used RabbitMQ before which gives lot of functionality out of the box, you can probably use the worker queues example from the tutorial, it can also persists messages in the queue.

I haven't used Amazon SQS before. Another tool you could use is Kafka.

See more
Kevin Deyne
Principal Software Engineer at Accurate Background · | 5 upvotes · 193.4K views
Recommends
on
RabbitMQRabbitMQ

Both would do the trick, but there are some nuances. We work with both.

From the sound of it, your main focus is "not losing messages". In that case, I would go with RabbitMQ with a high availability policy (ha-mode=all) and a main/retry/error queue pattern.

Push messages to an exchange, which sends them to the main queue. If an error occurs, push the errored out message to the retry exchange, which forwards it to the retry queue. Give the retry queue a x-message-ttl and set the main exchange as a dead-letter-exchange. If your message has been retried several times, push it to the error exchange, where the message can remain until someone has time to look at it.

This is a very useful and resilient pattern that allows you to never lose messages. With the high availability policy, you make sure that if one of your rabbitmq nodes dies, another can take over and messages are already mirrored to it.

This is not really possible with SQS, because SQS is a lot more focused on throughput and scaling. Combined with SNS it can do interesting things like deduplication of messages and such. That said, one thing core to its design is that messages have a maximum retention time. The idea is that a message that has stayed in an SQS queue for a while serves no more purpose after a while, so it gets removed - so as to not block up any listener resources for a long time. You can also set up a DLQ here, but these similarly do not hold onto messages forever. Since you seem to depend on messages surviving at all cost, I would suggest that the scaling/throughput benefit of SQS does not outweigh the difference in approach to messages there.

See more
MITHIRIDI PRASANTH
Software Engineer at LightMetrics · | 4 upvotes · 268.4K views
Needs advice
on
Amazon MQAmazon MQ
and
Amazon SQSAmazon SQS
in

I want to schedule a message. Amazon SQS provides a delay of 15 minutes, but I want it in some hours.

Example: Let's say a Message1 is consumed by a consumer A but somehow it failed inside the consumer. I would want to put it in a queue and retry after 4hrs. Can I do this in Amazon MQ? I have seen in some Amazon MQ videos saying scheduling messages can be done. But, I'm not sure how.

See more
Replies (1)
Andres Paredes
Lead Senior Software Engineer at InTouch Technology · | 1 upvotes · 205.4K views
Recommends
on
Amazon SQSAmazon SQS

Mithiridi, I believe you are talking about two different things. 1. If you need to process messages with delays of more 15m or at specific times, it's not a good idea to use queues, independently of tool SQM, Rabbit or Amazon MQ. you should considerer another approach using a scheduled job. 2. For dead queues and policy retries RabbitMQ, for example, doesn't support your use case. https://medium.com/@kiennguyen88/rabbitmq-delay-retry-schedule-with-dead-letter-exchange-31fb25a440fc I'm not sure if that is possible SNS/SQS support, they have a maximum delay for delivery (maxDelayTarget) in seconds but it's not clear the number. You can check this out: https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html

See more
Get Advice from developers at your company using StackShare Enterprise. Sign up for StackShare Enterprise.
Learn More
Pros of Amazon SQS
Pros of Redis
  • 62
    Easy to use, reliable
  • 40
    Low cost
  • 28
    Simple
  • 14
    Doesn't need to maintain it
  • 8
    It is Serverless
  • 4
    Has a max message size (currently 256K)
  • 3
    Triggers Lambda
  • 3
    Easy to configure with Terraform
  • 3
    Delayed delivery upto 15 mins only
  • 3
    Delayed delivery upto 12 hours
  • 1
    JMS compliant
  • 1
    Support for retry and dead letter queue
  • 1
    D
  • 886
    Performance
  • 542
    Super fast
  • 513
    Ease of use
  • 444
    In-memory cache
  • 324
    Advanced key-value cache
  • 194
    Open source
  • 182
    Easy to deploy
  • 164
    Stable
  • 155
    Free
  • 121
    Fast
  • 42
    High-Performance
  • 40
    High Availability
  • 35
    Data Structures
  • 32
    Very Scalable
  • 24
    Replication
  • 22
    Great community
  • 22
    Pub/Sub
  • 19
    "NoSQL" key-value data store
  • 16
    Hashes
  • 13
    Sets
  • 11
    Sorted Sets
  • 10
    NoSQL
  • 10
    Lists
  • 9
    Async replication
  • 9
    BSD licensed
  • 8
    Bitmaps
  • 8
    Integrates super easy with Sidekiq for Rails background
  • 7
    Keys with a limited time-to-live
  • 7
    Open Source
  • 6
    Lua scripting
  • 6
    Strings
  • 5
    Awesomeness for Free
  • 5
    Hyperloglogs
  • 4
    Transactions
  • 4
    Outstanding performance
  • 4
    Runs server side LUA
  • 4
    LRU eviction of keys
  • 4
    Feature Rich
  • 4
    Written in ANSI C
  • 4
    Networked
  • 3
    Data structure server
  • 3
    Performance & ease of use
  • 2
    Dont save data if no subscribers are found
  • 2
    Automatic failover
  • 2
    Easy to use
  • 2
    Temporarily kept on disk
  • 2
    Scalable
  • 2
    Existing Laravel Integration
  • 2
    Channels concept
  • 2
    Object [key/value] size each 500 MB
  • 2
    Simple

Sign up to add or upvote prosMake informed product decisions

Cons of Amazon SQS
Cons of Redis
  • 2
    Has a max message size (currently 256K)
  • 2
    Proprietary
  • 2
    Difficult to configure
  • 1
    Has a maximum 15 minutes of delayed messages only
  • 15
    Cannot query objects directly
  • 3
    No secondary indexes for non-numeric data types
  • 1
    No WAL

Sign up to add or upvote consMake informed product decisions

What is Amazon SQS?

Transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available. With SQS, you can offload the administrative burden of operating and scaling a highly available messaging cluster, while paying a low price for only what you use.

What is Redis?

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams.

Need advice about which tool to choose?Ask the StackShare community!

Jobs that mention Amazon SQS and Redis as a desired skillset
LaunchDarkly
Oakland, California, United States
What companies use Amazon SQS?
What companies use Redis?
See which teams inside your own company are using Amazon SQS or Redis.
Sign up for StackShare EnterpriseLearn More

Sign up to get full access to all the companiesMake informed product decisions

What tools integrate with Amazon SQS?
What tools integrate with Redis?

Sign up to get full access to all the tool integrationsMake informed product decisions

Blog Posts

Nov 20 2019 at 3:38AM

OneSignal

PostgreSQLRedisRuby+8
9
4624
Jun 6 2019 at 5:11PM

AppSignal

RedisRubyKafka+9
15
1632
GitHubDockerReact+17
40
36140
What are some alternatives to Amazon SQS and Redis?
Amazon MQ
Amazon MQ is a managed message broker service for Apache ActiveMQ that makes it easy to set up and operate message brokers in the cloud.
Kafka
Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design.
ActiveMQ
Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License.
Amazon SNS
Amazon Simple Notification Service makes it simple and cost-effective to push to mobile devices such as iPhone, iPad, Android, Kindle Fire, and internet connected smart devices, as well as pushing to other distributed services. Besides pushing cloud notifications directly to mobile devices, SNS can also deliver notifications by SMS text message or email, to Simple Queue Service (SQS) queues, or to any HTTP endpoint.
RabbitMQ
RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received.
See all alternatives