Ask HN: When would you go with Kinesis over SNS/SQS and why? | Hacker News Reader

Ask HN: When would you go with Kinesis over SNS/SQS and why?

4 points1penny42cents3 comments

In a previous project we went with SNS/SQS for our event bus, because of simplicity. I wondered towards the end if Kinesis would have been better.

The main reason in my mind being one less API/component, ordered streams, and replayability. SNS/SQS made it a bit painful to replay events. The counterpoint seems that Kinesis has some complexity around scalability that you might not need to worry about, depending on the usage.

But I've never used Kafka/Kinesis so I can't say. What are your thoughts?

  Message Brokers:
  - Amazon SNS + Mobile push notifications
  - Amazon SQS
  - Amazon EventsBridge
  - Amazon MQ for RabbitMQ
  - Amazon MQ for Apache ActiveMQ
  
  Pub/Sub:
  - AWS IoT Core for managed MQTT message broker
  - Amazon ElastiCache for Redis

  Append Only Logs:
  - Amazon Managed Streaming for Apache Kafka (Amazon MSK)
  - AWS Kinesis Data Streams
  - AWS Kinesis Data Firehose

  New RabbitMQ will have Append-Only Logs via RabbitMQ Streaming - not sure AWS already supports this

  Same for Redis Streams - not sure Amazon ElastiCache for Redis already supports this

Addition: Message Brokers: - Amazon SNS (for pub) + SQS (for sub)

I think the comparison of sqs/sns Vs eventbridge sounds more like what your mean

I find eventbridge gives better decoupling than sqs and is easier to configure

Reply on news.ycombinator.com