#kafka — Public Fediverse posts on home.social

Habr @[email protected] · 2026-07-23 · 06:02 UTC

Надёжная асинхронная коммуникация: повторы, дубликаты и dead letter queues

Представим обычную обработку заказа. Сервис заказов публикует событие order.created . Сервис склада получает его и резервирует товар в PostgreSQL. После успешной транзакции обработчик должен отправить RabbitMQ подтверждение ( Ack ), чтобы broker удалил сообщение из queue. Но процесс может остановиться после записи в PostgreSQL и до отправки Ack . RabbitMQ не знает, успел ли сервис зарезервировать товар. Broker видит только неподтверждённое сообщение, поэтому доставляет его ещё раз. С точки зрения доставки это правильное поведение. С точки зрения бизнеса один заказ теперь может зарезервировать товар дважды. Другой сбой возникает раньше: PostgreSQL временно недоступен, и обработчик не может начать работу. Если сразу вернуть сообщение в queue через отрицательное подтверждение Nack(requeue=true) , RabbitMQ почти немедленно доставит его снова. Пока база не восстановилась, все попытки будут бесполезными. Нужны задержка и ограничение числа повторов. При этом отложенное сообщение может пропустить вперёд более новые события, поэтому отдельно придётся решить вопрос порядка. Так одна операция превращается в несколько независимых участков: запись события, публикация, хранение в broker, обработка и подтверждение. Между соседними участками остаются моменты, когда одна сторона уже выполнила действие, а другая ещё не получила подтверждение. В статье разберём эти моменты по всему пути сообщения. Затем построим практическую схему для RabbitMQ и Go: добавим ограниченные повторы через retry queues, время жизни сообщения ( TTL ) и dead letter exchange, сделаем обработчик идемпотентным и определим, куда отправлять сообщения, которые не удалось обработать автоматически. В конце сравним этот подход с Kafka, NATS JetStream и Amazon SQS.

https://habr.com/ru/articles/1062002/

#rabbitmq #golang #go #kafka #архитектура #асинхронность #микросервисы #broker #queue #resilience

#resilience #queue #broker #микросервисы #асинхронность #архитектура

Jobs for Developers @[email protected] · 2026-07-22 · 12:05 UTC

SumUp is hiring (Senior) Backend Engineer - Global Bank

🔧 #golang #kotlin #aws #cicd #docker #kafka #kubernetes #postgresql #seniorengineer
🌎 Sofia, Bulgaria
⏰ Full-time
🏢 SumUp

Job details https://jobsfordevelopers.com/jobs/senior-backend-engineer-global-bank-at-sumup-com-dec-22-2025-a09296?utm_source=mastodon.world&utm_medium=social&utm_campaign=posting
#jobalert #jobsearch #hiring

#golang #kotlin #aws #cicd #docker #kafka

Jobs for Developers @[email protected] · 2026-07-22 · 12:05 UTC

SumUp is hiring (Senior) Backend Engineer - Global Bank

🔧 #golang #kotlin #aws #cicd #docker #kafka #kubernetes #postgresql #seniorengineer
🌎 Sofia, Bulgaria
⏰ Full-time
🏢 SumUp

Job details https://jobsfordevelopers.com/jobs/senior-backend-engineer-global-bank-at-sumup-com-dec-22-2025-a09296?utm_source=mastodon.world&utm_medium=social&utm_campaign=posting
#jobalert #jobsearch #hiring

#golang #kotlin #aws #cicd #docker #kafka

Habr @[email protected] · 2026-07-22 · 06:02 UTC

Эволюция Kafka as a Service: от факапа до чилаута

Я Анастасия, ведущий SRE-инженер РСХБ.Цифра. В этой статье я расскажу о том, как мы в App.Farm, PaaS-платформе Россельхозбанка, перешли от одной «большой» Kafka до реализации услуги «Kafka as a Service» c индивидуальными кластерами под ключ. Звучит просто, но за этим кроется сложный путь проб и ошибок.

https://habr.com/ru/companies/rshb/articles/1057934/

#kafka #infrastructure #development #appfarm #integration #paas

#paas #integration #appfarm #development #infrastructure #kafka