DDDevotion

Попалась статья про концепцию The Synchrony Budget. Основной посыл: взаимодействие между сервисами
должно быть настолько асинхронным, насколько это возможно, и настолько синхронным, насколько это необходимо.
И вроде бы да: мир в котором мы живем в большинстве случаев асинхронный: мы асинхронно заказываем такси, асинхронно получаем аппрув на наше заявление об отпуске, асинхронно торгуем на бирже, асинхронно переводим деньги. И в целом strong consistency переоценена и редко где нужна.
Но как всегда everything is a tradeoff! Как монолит намного проще микросервисной архитектуры (рекомендую ознакомиться с fallacies distributed system), так и синхронное взаимодействие намного проще асинхронного.

Вот моя версия fallacies asynchronous communication:

Заблуждения об асинхронной коммуникации
Часто встречающиеся ошибки, из-за которых распределённые системы становятся хрупкими и непредсказуемыми

1. Инфраструктура надёжна, поэтому о согласованности можно не думать
Полагаться на то, что платформа “всё сделает правильно”, опасно
→ Реальность: Сеть может моргнуть, сервисы — упасть, сообщения — потеряться. Согласованность должна быть заложена в архитектуру.

2. Сообщения будут обрабатываться в том порядке, в котором были отправлены
Опираться на порядок событий — прямой путь к скрытым багам и несогласованному состоянию
→ Реальность: Порядок доставки не гарантируется — используйте ключи сортировки или обрабатывайте события с учётом возможной перестановки.

3. Каждое сообщение будет обработано ровно один раз (exactly once)
Ожидание, что каждое сообщение придёт ровно один раз, может привести к логическим ошибкам из-за повторной обработки.
→ Реальность: Почти все системы доставляют сообщения по меньшей мере один раз (at least once) — логика обработки должна быть идемпотентной.

4. В асинхронных системах нет гонок (race condition)
Асинхронность не избавляет от проблем с параллелизмом
→ Реальность: Задержки, повторы и параллельная обработка могут приводить к состоянию гонки. Требуется защита общего состояния и продуманная архитектура.

5. Консьюмер обработает сообщение быстро и предсказуемо
Расчёт на стабильное время обработки приводит к неправильным архитектурным решениям
→ Реальность: Обработка может занять секунды или минуты — в зависимости от нагрузки, состояния системы или внешних зависимостей. Нужно заранее определить: как долго ждать, когда реагировать, что делать при задержке.

6. Поддерживать контракты сообщений и отслеживать кто что продюсит и консьюмит просто
Игнорирование связей между компонентами приводит к неожиданным сбоям
→ Реальность: В асинхронных системах компоненты слабо связаны — используйте реестры схем, определяйте владельцев и версионируйте контракты.

7. Асинхронность снижает связанность (coupling), значит менять контракты легко
Считать, что слабая связанность позволяет менять сообщения без последствий — опасное заблуждение
→ Реальность: Форматы сообщений — это публичные API. Изменения должны быть обратимо совместимыми, задокументированными и согласованными.

8. Достаточно просто отправить сообщение — оно обработается
Игнорирование доставки приводит к потерянным данным и бесшумным ошибкам
→ Реальность: Без гарантии доставки и мониторинга невозможно быть уверенным, что сообщение дошло — используйте dead-letter очереди, логгирование и метрики доставки.

9. Повторить попытку — значит решить проблему
Безграничные повторы создают нагрузку, дубли и повторяющиеся ошибки
→ Реальность: Нужны ограничения на повторы, экспоненциальные задержки, таймауты и dead-letter очереди — повтор сам по себе проблему не решает.


Асинхронное взаимодействие добавляет сложности и я НЕ рекомендую делать выбор по умолчанию в пользу асинхронщины. А если и выбирать, то не забывайте об этих заблуждениях!

Обсудим? Что добавили бы? Какой выбор по умолчанию у вас?

www.tg-me.com/us/DDDevotion/com.dddevotion/405

4.8K viewsedited  Apr 5 at 15:44

Попалась статья про концепцию The Synchrony Budget. Основной посыл: взаимодействие между сервисами
должно быть настолько асинхронным, насколько это возможно, и настолько синхронным, насколько это необходимо.
И вроде бы да: мир в котором мы живем в большинстве случаев асинхронный: мы асинхронно заказываем такси, асинхронно получаем аппрув на наше заявление об отпуске, асинхронно торгуем на бирже, асинхронно переводим деньги. И в целом strong consistency переоценена и редко где нужна.
Но как всегда everything is a tradeoff! Как монолит намного проще микросервисной архитектуры (рекомендую ознакомиться с fallacies distributed system), так и синхронное взаимодействие намного проще асинхронного.

Вот моя версия fallacies asynchronous communication:

Заблуждения об асинхронной коммуникации
Часто встречающиеся ошибки, из-за которых распределённые системы становятся хрупкими и непредсказуемыми

1. Инфраструктура надёжна, поэтому о согласованности можно не думать
Полагаться на то, что платформа “всё сделает правильно”, опасно
→ Реальность: Сеть может моргнуть, сервисы — упасть, сообщения — потеряться. Согласованность должна быть заложена в архитектуру.

2. Сообщения будут обрабатываться в том порядке, в котором были отправлены
Опираться на порядок событий — прямой путь к скрытым багам и несогласованному состоянию
→ Реальность: Порядок доставки не гарантируется — используйте ключи сортировки или обрабатывайте события с учётом возможной перестановки.

3. Каждое сообщение будет обработано ровно один раз (exactly once)
Ожидание, что каждое сообщение придёт ровно один раз, может привести к логическим ошибкам из-за повторной обработки.
→ Реальность: Почти все системы доставляют сообщения по меньшей мере один раз (at least once) — логика обработки должна быть идемпотентной.

4. В асинхронных системах нет гонок (race condition)
Асинхронность не избавляет от проблем с параллелизмом
→ Реальность: Задержки, повторы и параллельная обработка могут приводить к состоянию гонки. Требуется защита общего состояния и продуманная архитектура.

5. Консьюмер обработает сообщение быстро и предсказуемо
Расчёт на стабильное время обработки приводит к неправильным архитектурным решениям
→ Реальность: Обработка может занять секунды или минуты — в зависимости от нагрузки, состояния системы или внешних зависимостей. Нужно заранее определить: как долго ждать, когда реагировать, что делать при задержке.

6. Поддерживать контракты сообщений и отслеживать кто что продюсит и консьюмит просто
Игнорирование связей между компонентами приводит к неожиданным сбоям
→ Реальность: В асинхронных системах компоненты слабо связаны — используйте реестры схем, определяйте владельцев и версионируйте контракты.

7. Асинхронность снижает связанность (coupling), значит менять контракты легко
Считать, что слабая связанность позволяет менять сообщения без последствий — опасное заблуждение
→ Реальность: Форматы сообщений — это публичные API. Изменения должны быть обратимо совместимыми, задокументированными и согласованными.

8. Достаточно просто отправить сообщение — оно обработается
Игнорирование доставки приводит к потерянным данным и бесшумным ошибкам
→ Реальность: Без гарантии доставки и мониторинга невозможно быть уверенным, что сообщение дошло — используйте dead-letter очереди, логгирование и метрики доставки.

9. Повторить попытку — значит решить проблему
Безграничные повторы создают нагрузку, дубли и повторяющиеся ошибки
→ Реальность: Нужны ограничения на повторы, экспоненциальные задержки, таймауты и dead-letter очереди — повтор сам по себе проблему не решает.


Асинхронное взаимодействие добавляет сложности и я НЕ рекомендую делать выбор по умолчанию в пользу асинхронщины. А если и выбирать, то не забывайте об этих заблуждениях!

Обсудим? Что добавили бы? Какой выбор по умолчанию у вас?

BY DDDevotion