In this #InfoQ podcast, Somtochi Onyekwere breaks down:
• Recent developments in #DistributedDataSystems
• How to achieve fast, eventually consistent replication across distributed nodes
• Using #CRDTs (Conflict-free Replicated Data Types) to resolve data conflicts seamlessly
🎧 Listen here: https://bit.ly/49OiNaE
The Saga pattern embraces eventual consistency. Between steps, the system may hold a briefly inconsistent state. A debit can commit before its corresponding credit is processed — an accepted trade-off for availability.
The Saga pattern embraces eventual consistency. Between steps, the system may hold a briefly inconsistent state. A debit can commit before its corresponding credit is processed — an accepted trade-off for availability.
@visuallyperfect MAX как кейс: типичные баги, архитектурные провалы и почему это закономерно
Если отбросить маркетинг и смотреть на MAX как на инженерный продукт, то картина довольно прозрачная: перед нами типичный “быстро собранный мессенджер”, который пытаются масштабировать раньше, чем он стал устойчивым.
Разберём по слоям.
---
1. Доставка сообщений: не гарантия, а вероятность
Симптоматика знакома: — сообщения приходят пачками
— дублируются
— часть переписки просто исчезает
Это классический признак плохо настроенной eventual consistency. Судя по поведению, backend не обеспечивает строгую гарантию доставки (at-least-once / exactly-once), а плавает где-то между retry-логикой и race conditions.
Что это значит на практике: — повторная отправка → дубликаты
— сбой на клиенте → рассинхрон
— reconnect → “догоняющие” сообщения
Если система не умеет детерминированно разрешать конфликты — это не баг, это следствие архитектуры.
---
2. Push-уведомления: рассинхрон между слоями
Типичный кейс: — пуш пришёл → сообщения нет
— сообщение есть → пуша нет
— всё приходит через 10–15 минут
Основной подозреваемый — интеграция с Firebase Cloud Messaging.
Но проблема глубже: — нет единого источника истины (source of truth)
— пуш и сообщение живут в разных транзакционных контекстах
— отсутствует нормальная idempotency
В нормальной системе push — это просто триггер, а не отдельная сущность с собственной логикой.
---
3. Клиент: UI как узкое место
Фризы, дерганый скролл, зависания — это не “мелкие баги”, это сигнал:
— список сообщений плохо виртуализирован
— перерасчёт layout идёт на основном потоке
— есть memory leaks
Типичный стек-проблем: — RecyclerView захлёбывается на больших чатах
— битмапы не освобождаются
— кеширование сделано “на глаз”
В результате: UI начинает быть bottleneck быстрее, чем сеть.
---
4. Медиа: слабое место всех “быстрых” мессенджеров
Симптомы: — фото не уходят
— видео ломается
— загрузка зависает
Это почти всегда: — нестабильный upload (chunking / retry)
— проблемы на CDN
— отсутствие контроля целостности
Если нет нормального pipeline: encode → upload → verify → deliver
— медиа будет ломаться системно.
---
5. Сессии и авторизация
Самый раздражающий класс багов: — выкидывает из аккаунта
— слетает история
— “переавторизуйтесь”
Это почти гарантированно: — проблемы с токенами
— гонки при обновлении сессии
— рассинхрон между клиентом и сервером
Если auth не атомарен — вся система начинает вести себя хаотично.
---
6. Краши и память
Если приложение: — падает при отправке файлов
— жрёт RAM
— умирает в фоне
значит: — lifecycle не контролируется
— ресурсы не освобождаются
— тестирование на edge-кейсах отсутствует
Это не “надо допилить” — это долг на уровне архитектуры клиента.
---
7. Безопасность: отсутствие ясной модели
Ключевой вопрос — не “есть ли шифрование”, а: кто контролирует ключи и где происходит дешифровка?
Если нет прозрачной end-to-end модели, как у Signal, то: — сервер потенциально видит всё
— безопасность декларативная
Даже Telegram с его спорной моделью MTProto выглядит более зрелым решением на фоне MAX.
---
8. Масштабирование: система не держит нагрузку
Периодические “падения” — это не случайность.
Это означает: — нет горизонтального масштабирования
— нет нормального load balancing
— система не тестировалась под реальную нагрузку
Типичная ошибка: сначала релиз → потом попытка масштабировать → потом firefighting.
---
Итог
MAX — не “глючный мессенджер”.
MAX — это: — backend без строгих гарантий
— клиент без оптимизации
— инфраструктура без запаса прочности
Все наблюдаемые баги — не случайные. Они логично следуют из архитектурных решений.
---
Почему это важно
Такие системы создают ложное ощущение стабильности: пока нагрузка низкая — “вроде работает”.
Но при росте: — баги становятся нормой
— доверие падает
— продукт превращается в технический долг
---
Коротко
Если описать одной строкой:
MAX сейчас — это не продукт уровня production-grade мессенджера, а MVP, который по ошибке выпустили в массовое использование.
---
Если нужно, могу разобрать: — как бы выглядела нормальная архитектура такого мессенджера
— или сравнить MAX с WhatsApp / Signal / Telegram на уровне протоколов и backend-дизайна
#MAX
#Мессенджеры
#Инженерия
#SoftwareEngineering
#Backend
#DistributedSystems
#EventualConsistency
#MessageQueues
#PushNotifications
#FCM
#AndroidDev
#MobileDev
#UX
#Performance
#MemoryLeaks
#Scalability
#Reliability
#HighLoad
#DevOps
#Microservices
#CDN
#Security
#EndToEndEncryption
#Signal
#Telegram
#ITАнализ
For most Internet apps, #EventualConsistency works fine when strict guarantees aren’t needed.
Conflict-free Replicated Data Types (#CRDTs) let independent replicas accept writes and update data without coordination.
🎙️ Dive deeper in the #InfoQ #podcast with Somtochi Onyekwere, Software Engineer at Fly.io!
🎧 Listen now (#transcript included): https://bit.ly/49OiNaE
#DistributedSystems #DataEngineering #AI #ConflictFreeReplicatedDataTypes
Dealing with #EventualConsistency, and Causal Consistency using Predictable Identifiers
https://www.architecture-weekly.com/p/dealing-with-eventual-consistency
Let's follow up today on fighting with eventual consistency, causal consistency and how predictable ids can help you with that. We'll take on my real project: decoupling file upload from linking it in various places in the application.
@eric tweeted yesterday about the ‘itchy’ concept of #EventualConsistency, it’s ‘itchy’ because in the beginning the Word was Codd and ‘its aye been that way’, but it’s aye been that way is a poor reason to do anything. Rules are for the protection of the inexperienced, & the guidance of the experienced. Much to think about, and much to learn.
Still, if you are learning, you ain’t dead, yet. #php #database
Proposing to implement a distributed system without considering things such as #CAP, Transactions, #EventualConsistency or even...error handling! 🤦 🤦♂️
They are probably even unaware of the fact that it is a distributed system in the first place.
What has happened to our #society that even basic fundamentals are turned a blind eye on!?
I'm literally scared...
InfoQ
Kanishka Naik
Alterego_Midshipman
Nicolas Fränkel 🇪🇺🇺🇦🇬🇪
Stu Watts
robrich
MelHamnavoe
Jan 
