Привет, архитекторы, разработчики и неопределившиеся! Меня зовут Сергей Врунов. Я работаю в ВТБ и занимаюсь развитием ИТ-архитектуры. Все мы сталкиваемся с религиозными «архитектурными» дискуссиями и производственными конфликтами на ровном месте. Кажется, у вас есть классное решение или предложение, но почему оно так плохо заходит или вообще не заходит? Что делать? Какой профиль успеха архитектора?

Архитектурная психология! Читайте наш «Кодекс архитектора», создавайте на его основе свой и приносите пользу организации.

Иногда при разработке highload-продукта возникает ситуация, когда надо обработать не максимально большое количество запросов, а наоборот — ограничить количество запросов в единицу времени. В нашем случае это количество отправляемых push-уведомлений конечным пользователям. Подробнее об алгоритмах rate limiting, их плюсах и минусах — под катом.

​ В этой статье я покажу как решить одну из проблем, возникающих при использовании распределенных очередей задач — регулирование пропускной способности очереди, или же, более простым языком, настройка ее rate limit'a. В качестве примера я возьму python и свою любимую связку Celery+RabbitMQ, хотя алгоритм, который я использую, никак не зависит от этих инструментов и может быть реализован на любом другом стэке.

So what's the problem?

​ Для начала пара слов о том, какую проблему я вообще пытаюсь решить. Дело в том, что 99.9% сервисов в интернете запрещают бесконтрольно закидывать их сотнями/тысячами запросов в секунду, угрожая дать в ответ какой-нибудь 403 или 500. Нет, ну правда, жалко им чтоле? Иногда таким сервисом может выступать даже своя собственная БД… Вобщем, доверять нынче нельзя никому, поэтому приходится себя как-то сдерживать.

​ Конечно, если вся работа ведется внутри 1го процесса, то никакой проблемы нет, но т.к мы работаем с Celery, то у нас может быть не только N процессов (далее воркеров), но и M машин, и задача все это дело синхронизировать уже не кажется столь тривиальной.

Приветствую, хабровчане. В далёком 1998-м я поступил в вуз на инженера-программиста и ещё в первом семестре реализовал свой первый коммерческий программный проект. Нет, это не курсовая для сокурсников, как вы могли бы подумать. Это была простенькая система складского учета для знакомых коммерсантов (работает, кстати, и поныне). Забавно, но она и стала тем триггером, который через пару лет надолго привел меня в коммерческую продуктовую разработку сперва на позицию разработчика, потом тимлида, аналитика…

В минувшие годы десятилетия довелось заниматься и решениями, которые создают люди, и людьми, которые создают решения, а с недавних пор и сам тружусь архитектором решений. Казалось бы, карьерный сдвиг очевиден. Даже более того – кардинально изменились масштаб, сложность, инструменты, возможности... Но что примечательно, фактически я до сих пор остаюсь на стыке бизнеса и работающих программных систем. Так чем же в действительности занимаются архитекторы решений, и не вымрут ли они, прежде чем очередной первокурсник защитит свой диплом? Давайте разбираться.