Получатель записал заказ в базу, но соединение оборвалось до того, как отправитель получил ответ. Нужно ли отправлять вебхук повторно? Если не отправить, можно потерять событие. Если отправить, можно создать второй заказ.
С такого случая удобно начинать разговор о доставке. HTTP-клиент умеет сделать POST, но по таймауту не скажет, что произошло на другом конце соединения. Решать, когда повторять запрос и как обрабатывать повтор, придётся обеим сторонам.
Недавно мне дали тестовое задание на проектирование интеграции между 1С и Yandex 360. На первый взгляд задача выглядела достаточно прямолинейно: 1С формирует письмо, дальше его нужно передать в почтовую систему, отправить и получить информацию о результате. Но в исходном ТЗ не было отдельного сервиса на Go. Я добавил его сам. И в этой статье хочу разобрать не столько само тестовое задание, сколько процесс принятия архитектурного решения: зачем вообще добавлять ещё один компонент и в какой момент он действительно оправданЧитать полностью »
Я делаю конструктор, в котором люди без программирования собирают Telegram‑ботов и мини‑приложения. Каждому пользователю нужен свой бот со своим токеном, и в какой‑то момент встаёт вопрос: как это всё держать, чтобы хостинг не стоил как самолёт. Расскажу, к чему я пришёл, с замерами, и где у этой схемы потолок.
Самое очевидное решение — запускать на каждого бота свой процесс с long polling. Оно же самое плохое: сто ботов — сто процессов, каждый держит соединение и память, даже если боту никто не пишет неделями.
Платформа массовых email-рассылок, десяток крупных почтовых хостеров на том конце и рассылки на сотни тысяч адресов каждая. Принимают почту все по-своему — свой темп, свой размер пачки, своя реакция на временный отказ, свои представления о том, как быстро новому домену-отправителю позволено набирать обороты, — так что рассылка на миллион адресов одним потоком физически не едет: она сразу разваливается на несколько групп отправки, по одной на принимающую сторону, и дальше каждая живёт своей жизнью.
Моей первой большой самостоятельной работой программиста была инвентаризация celery-задач. Нам с товарищем по бэкенду достался легаси-проект товарно-учетного приложения. С горем пополам перевезли его из Hetzner в родное «облако» и поняли, что срочно необходимо всё документировать, очищать и структурировать. Пока коллега упаковывал приложение в контейнеры, я занялся Celery, так как на этой библиотеке было завязано много бизнес-логики.
Пока группировал и отлаживал задачи, определял им очереди, нашел в документации загадочное autoscaleЧитать полностью »
Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.
Типичная ситуация: один сервис добавил сообщение в очередь, другой сервис его прочитал, но из-за ошибки или рестарта сервиса не смог передать дальше. Сообщение потеряно.
В логах при этом не всегда есть что-то полезное, и часто всё заканчивается тем, что разработчики идут ругаться: «Почему в нашей очереди нет вашего сообщения?»
Вы не используете очередь? Вы просто не умеете её готовить. Но прежде чем этому научиться, нужно разобраться, что это вообще такое и где это применяется. Потому что большинству достаточно 10 000 запросов в секунду, а это дает любой брокер. Но если вам нужно больше, придется погрузиться в очереди достаточно глубоко.
Расскажу, что такое очереди, зачем они нужны и как работают. На примере нескольких сценариев объясню, как устроены очереди и какие есть решения. Какие у очередей самые распространенные проблемы и как их избежать. В чем отличия брокеров, их плюсы и минусы, и как все это использовать в своих целях.
Существует миф, что создавать приложения для iOS или Android проще, чем быть, скажем, бэкенд-разработчиком. Разумеется, это не так: в работе с любой платформой есть свои сложности, всюду возникают неочевидные проблемы, требующие навыков в предметной области и за её пределами. Роман Абузяров из команды Яндекс.Чатов подготовил доклад о своих нескольких задачах, который показывает, насколько широкими знаниями должен обладать специалист по iOS. Доклад предназначен для начинающих и junior-разработчиков.
Читать полностью »
Мой сайт, которым я занимаюсь в качестве хобби, предназначен для хранения интересных домашних страниц и персональных сайтов. Эта тема стала интересовать меня в самом начале моего пути в программировании, в тот момент меня восхищало нахождение больших профессионалов, которые пишут о себе, своих увлечениях и проектах. Привычка открывать их для себя осталась и сейчас: почти на каждом коммерческом и не очень сайте я продолжаю заглядывать в футер в поисках ссылок на авторов.
Читать полностью »
