Вот, кстати, ещё немного технического контента. Возвращаемся к брокерам событий.

Существует два архитектурных подхода и каждый имеет своих ярких представителей, знакомых каждому, кто хоть раз работал с брокерами вообще.

Первый - как в SQS или RabbitMQ. Брокер держит состояние на каждую пару «событие + подписчик». Пришло событие, у него 5 подписчиков - брокер материализует 5 строк доставки и сам катает их по жизненному циклу: retry, backoff, dead-letter, таймауты видимости.

Второй - как в Kafka. Брокер хранит просто журнал. Один общий лог событий. А у каждого подписчика - курсор, позиция «вот досюда я всё обработал». Пришло событие - подписчику прилетает только сигнал «есть новое», он сам приходит, читает всё после своего курсора, обрабатывает и двигает курсор дальше.

Выбор архитектуры зависит от предпочтений разработчика, но поскольку в данный момент мы работаем конкретно с Chatium, то у него есть одна архитектурная особенность:
- Общее количество строк на таблицу не может превышать 1 млн.;
- Размер JSON-представления для одной строки не должен превышать 2 MB;
- Оптимальный размер JSON-представления для одной строки должен быть менее 8 KB.

И вот в первой модели нам нужна таблица доставки, которая раздувается с космическими скоростями, а во второй нет.

Но это я всё вот к чему...

Когда мы даём задачу ИИ спроектировать какую-то систему - это "чёрный ящик" до тех пор, пока мы не вникнем в то, что именно было спроектировано.

Когда таблица упрётся в лимит - мы не будем знать, в чём дело. И ИИ тоже знать не будет. И всё полетит к чертям.

Поэтому нам ОБЯЗАТЕЛЬНО нужна спецификация, которую мы ЛИЧНО вычитываем, без использования ИИ. Разбираемся, вникаем, правим.