Работаю в IT больше 15 лет. Чем только не занимался, но всегда следовал правилу - каждые майские праздники я пытаюсь применить на практике что-то новое. В этом году я прочитал книгу Event Driven Microservices и загорелся потрогать Kafka как настоящий брокер событий, а не сообщений. Идей было много, но мне хочется проверить все это под реальной нагрузкой, что сразу привело в телеграм боты, где получить +- 1000 пользователей труда не составляет.  Я все детство провозился с ASCII играми в DOS и идея пришла сама собой. В телеграме я нашел кучу текстовых квестов, но с графикой не было ни одного. Я провел небольшое исследование, как телеграм реагирует на большое количество emoji и выявил пару проблем: Есть ограничение на 13 символов в строке, до момента, как телега не будет все ломать На андроид, начиная с 50 символа телеграм меняет стилистику emoji Первое решается легко, а второе потребовало добавить шапку из элементов: Когда с идеей определился, настал момент выбирать технологии к реализации: У меня есть кластер Kubernetes и несколько серверов Для хранения данных я установил PostgreSQL, так как хорошо его знаю Написал несколько скриптов на "Bashsible" для потребностей DevOps Установил Kafka. Версия с Zookeeper и без репликации В дальнейшем добавил Redis, но об этом позже Сервисы решил писать на Java со Spring Boot Для хранения и аналитики логов поставил ELK Первая проблема с которой я столкнулся - это настройка Webhook в телеграме. Он категорически отказывался принимать мой сертификат с ingress контроллера. Хотя, любой frontend сервис, размещенный на кластер, отлично работал в браузере через https. Я провозился несколько часов, пока не понял в чем дело. Необходимо загрузить в tls секрет всю цепочку сертификатов. Спасибо доброму человеку, написавшего эту статью: Сшиваем SSL-сертификаты Вторая - это ограничения Telegram. В первой версии я реализовал MMO. Персонажи обновлялись сразу во всех чатах, где их можно увидеть.  Но лимиты телеграма быстро вернули меня в реальность и я решил оставить эту затею. Затем пришла пора входного потока событий. Если изменять сообщение чаще чем раз в секунду, то сразу попадаешь под ошибку подобную этой: К этому моменту я разбил всю систему на 3 группы микросервисов: Получение событий из Telegram. Сервис обладает POST контроллером для получения действий пользователя из чата с ботом. А также Kafka Producer, отправляющего данные сообщения в обработку. Позже, я добавил к этому сервису Redis для проверки частоты кликов пользователя на кнопки в боте Обработчики событий. В нее входят: Consumer сообщений из входного потока сообщений, и producer в выходной поток сообщений Сервисы карты мира Объекты для взаимодействия (мобы, NPC, здания, лут и т.д.) Пользователи и их характеристики Квестовый движок (Состояния, диалоги, скрипты) Отправка событий в Telegram. Сервис получает сообщения из выходного потока и отправляет их в телеграм. Попутно проверяя их на лимиты. Я искал способ на проверку частоты отправки и наткнулся на такую возможность Redis как PX, т.е. время жизни объекта. При получения события я проверяю на наличие объекта по ключу(id чата пользователя), а затем записываю его опять с параметром px = 1000ms. Если при получении события объект в Redis существует, то я игнорирую данное событие. PostgreSQL очень помог на этапе создания квестового движка. Я активно использую индексы с условием и функциональные констрейнты. Также, очень помогла и сократила размер кода такая конструкция в запросах как INSERT ... on conflict do  Я получил горизонтально-масштабируемую систему, позволяющую довольно легко внедрять новый функционал. При повышении нагрузки - я добавляю партиции в топики Kafka и увеличиваю кол-во pod'ов, содержащие consumer’ы. Я накидал небольшой сюжет и опубликовал все это на нескольких ресурсах. Полет нормальный, народ требует продолжения, MMO и PvP Если тоже хотите присоединиться к волшебному миру, то добро пожаловать в EmojiHeroesBot Профессионально говорю «Это просто!»