• Кэширование данных (да, банально и скучно, но это классный инструмент для кэширования и обойти стороной этот кейс, кажется будет не правильно)
• Работа с очередями на базе redis
• Организация блокировок (mutex)
• Делаем систему rate-limit
• Pubsub — делаем рассылки сообщений на клиенты

Многие сервисы предоставляют возможность взаимодействовать с ними не только обычным пользователям через отточенные и оптимизированные графические интерфейсы, но и внешним разработчикам из своих программ через API. При этом сервисам важно контролировать нагрузку на свою инфраструктуру. В ситуации с обычными пользователями большинство проблем с нагрузкой не возникнет из-за контроля кода приложения, отправляющего запросы к сервису, со стороны разработчиков сервиса (пользователей, пытающихся что-то делать в приложении за рамками предложенных разработчиками интерфейсов и задокументированных возможностей мы в данной статье не рассматриваем). В случае со внешними разработчиками простор для создания нагрузки на сервис ограничен только фантазией этих самых внешних разработчиков. Чтобы немного ограничить этот простор, стала распространена практика введения ограничений на количество запросов в единицу времени к API сервиса. 

Мы уже рассказывали о том, как можно реализовать эти ограничения если вы сами разрабатываете API сервиса, сегодня хотим рассказать о том, как жить с «клиентской» стороны и удобно пользоваться ограниченным по количеству запросов API.

• Помогут немного размять мозги;
• Возможно, кому-то помогут узнать новые понятия из математики и статистики.

Привет, меня зовут Максим, я бэкенд-разработчик в ManyChat. 

Эта статья – о нашем переходе на PHP8. Однажды мы решили немного поисследовать – посмотреть, чего нам будет стоить возможный переход на новую версию, и запланировать эти работы на следующий год, сразу на 8.1. Перспектива переезда тогда вызывала у нас чувства примерно как на КДПВ: от мыслей обо всех тестах и внешних зависимостях было немного неуютно.

Однако в процессе исследования выяснилось, что нельзя просто так взять и остановиться. Одно за другим, и вот мы уже полностью на PHP 8. 

Эта статья – о шагах, из которых складывался переезд, и проблемах, которые мы встретили в процессе. Надеюсь, статья будет полезна для тех, кому ещё только предстоить перейти на PHP 8 – поможет подготовиться хотя бы морально. Для всех остальных (кто уже на PHP 8 или не собирается) – давайте сверимся по ощущениям.

Привет, меня зовут Влад, я фронтенд-разработчик в ManyChat. В этой статье я расскажу, как мы писали сервис для проведения обучающих кампаний в продукте, и почему важна хорошая проработка задачи на раннем этапе.

Привет! Меня зовут Антон Поляков, и я разрабатываю аналитическое хранилище данных и ELT-процессы в ManyChat. 

Несколько лет назад мы выбрали Snowflake как сервис для нашей дата-платформы. С ростом объемов данных до сотен миллионов строк (спойлер: а затем и до десятков миллиардов), мы задались вопросом: «Как тратить меньше времени на расчет запросов для ежедневной отчетности?». Идеальным вариантом было использование материализованных представлений, позволяющих обращаться к предварительно вычисленным результатам расчета витрин гораздо быстрее, чем к исходным данным.

Мы могли отдать управление нашим пайплайном таким популярным сегодня инструментам для трансформации данных, как, например, dbt, Matillion или Dataform. Однако, в начале 2020 года ни у одного из них не было возможности тонкой кастомизации под нужды Snowflake и ManyChat. К тому же, нам не хотелось платить за еще один сторонний инструмент. Так, мы приняли решение изобрести собственный велосипед для работы с материализацией данных. Именно об этом я сегодня и расскажу.