Вот, кстати, ещё немного технического контента. Возвращаемся к брокерам событий. — 2 июля 2026 г. в 10:45:42.055
Вот, кстати, ещё немного технического контента. Возвращаемся к брокерам событий. Существует два архитектурных подхода и каждый имеет своих ярких представителей, знакомых каждому, кто хоть раз работал с брокерами вообще. Первый - как в SQS или RabbitMQ. Брокер держит состояние на каждую пару «событие + подписчик». Пришло событие, у него 5 подписчиков - брокер материализует 5 строк доставки и сам катает их по жизненному циклу: retry, backoff, dead-letter, таймауты видимости. Второй - как в Kafka. Брокер хранит просто журнал. Один общий лог событий. А у каждого подписчика - курсор, позиция «вот досюда я всё обработал». Пришло событие - подписчику прилетает только сигнал «есть новое», он сам приходит, читает всё после своего курсора, обрабатывает и двигает курсор дальше. Выбор архитектуры зависит от предпочтений разработчика, но поскольку в данный момент мы работаем конкретно с Chatium, то у него есть одна архитектурная особенность: - Общее количество строк на таблицу не может превышать 1 млн.; - Размер JSON-представления для одной строки не должен превышать 2 MB; - Оптимальный размер JSON-представления для одной строки должен быть менее 8 KB. И вот в первой модели нам нужна таблица доставки, которая раздувается с космическими скоростями, а во второй нет. Но это я всё вот к чему... Когда мы даём задачу ИИ спроектировать какую-то систему - это "чёрный ящик" до тех пор, пока мы не вникнем в то, что именно было спроектировано. Когда таблица упрётся в лимит - мы не будем знать, в чём дело. И ИИ тоже знать не будет. И всё полетит к чертям. Поэтому нам ОБЯЗАТЕЛЬНО нужна спецификация, которую мы ЛИЧНО вычитываем, без использования ИИ. Разбираемся, вникаем, правим.