Чем AWS SQS отличается от Kafka и когда выбирать каждый из них?

SQS и Kafka решают похожую задачу — передачу сообщений между сервисами, но их модели принципиально разные. SQS — это классическая очередь: продюсер кладёт сообщение, один из потребителей его забирает и после успешной обработки удаляет. Kafka — это распределённый append-only лог, где сообщения хранятся заданное время, а потребители читают их по своим offset-ам независимо друг от друга.

Ключевые различия

• Модель доставки: SQS — point-to-point (одно сообщение одному потребителю), Kafka — publish/subscribe с возможностью нескольких consumer groups.
• Хранение: SQS удаляет сообщение после подтверждения, Kafka хранит по retention (часы, дни, бесконечно).
• Порядок: SQS гарантирует порядок только в FIFO-очередях и с ограничениями, Kafka — порядок внутри партиции.
• Пропускная способность: Kafka масштабируется до миллионов сообщений в секунду, SQS — до тысяч на стандартной очереди.
• Эксплуатация: SQS полностью managed, Kafka требует кластера (или MSK/Confluent).

Пример: продюсер в Kafka

from kafka import KafkaProducer
import json

producer = KafkaProducer(
    bootstrap_servers='localhost:9092',
    value_serializer=lambda v: json.dumps(v).encode()
)

producer.send('orders', {'id': 1, 'status': 'created'})
producer.flush()  # дождаться отправки

Пример: отправка в SQS

import boto3

sqs = boto3.client('sqs')
sqs.send_message(
    QueueUrl='https://sqs.eu-west-1.amazonaws.com/123/orders',
    MessageBody='{"id": 1, "status": "created"}'
)

Когда что выбирать

• SQS: простые фоновые задачи, разгрузка API, retry-механизмы, когда нужен один потребитель и не важна история.
• Kafka: event sourcing, стриминг аналитики, CDC, интеграция множества сервисов через единый поток событий, replay данных.

Итог: если нужна простая надёжная очередь без эксплуатации — берите SQS. Если строите событийную платформу с несколькими потребителями, повторным чтением и высоким throughput — Kafka.