Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Tinder’s API Gateway Handles A Billion Swipes Per Day Очередная статья о том, как в компании решали тех проблему. Сегодня это тиндер, который, из-за нагрузки, написал собственный гейтвей в 2020 году. Текст начинается с описания проблемы: 500 сервисов, деплой каждого требовал обновлений в роутах, использовались разные гейтвеи, сессии обрабатывались по разному и так далее. При этом, пришлось фильтровать вредоносный трафик. Далее описывается почему существующие решения не подошли и как сделали Tinder API Gateway (фреймворк поверх Spring Cloud Gateway). По сути, это toolkit для создания гейтвеев, в котором конфиг описывается в yaml или json файле. Далее описывается как происходит старт гейтвея и как происходит Request Lifecycle. #how_it_works ————————————— Solving Double Booking at Scale Double booking — ситуация, при которой один тот же ресурс бронируется двумя людьми одновременно. Реализация букинга «в лоб» потребует написать два запроса: получить информацию, после чего обновить запись с бронированием, если место свободно. При этом, между запросами появляется временной лаг, из-за чего и возникает проблема. В тексте найдете описание проблемы двойного букинга. А также описание четырех вариантов решения: - Pessimistic locking — блокируем ресурс. Убирает гонку, но при этом замедляется выполнение логики, появляются риски с deadlock и проблемы с масштабированием; - Optimistic locking — храним версии, вместо блокировки. Быстрее пессимистичного лока, масштабируется и чтение быстрее. При этом возникают конфликты, повышается нагрузка на бд; - In-memory Distributed Locking — лочим в кэше. Быстро, но существует риск потери данных, кэш может отвалиться и блокировки не сняться; - Virtual Waiting Queue — переводим букинг в асинхронный мир через очередь. Scalability на уровне, в UX пропадают сообщения об ошибках и справедливость букинга. Из минусов — имплементация требует ресурсов и навыков, плюсом работа с событиями. В конце найдете сводную таблицу с плюсами и минусами каждого из подходов. Русский перевод #race_condition #consistency ————————————— Dealing with Race Conditions in Event-Driven Architecture with Read Models Восемь лет назад, если нужен определенный порядок событий, то задумывался о распределенных блокировках, гарантиях, кафке и так далее. Спустя время пришел к тому, что в первую очередь думаю о том, что стоит изучить границы элементов системы и коммуникациями, либо же иду к бизнесу переделывать бизнес процессы (если возможно). По ссылке выше, найдете совет, который поможет избавиться от проблемы ордеринга, для чего предлагается вспомнить о фантомной записи, собирающей данные и принимающей решение, что делать дальше. Текст начинается с мысли, что событие с позиции продюсера — факт, а вот со стороны консьюмера — что-то похожее на «слух», что придется перепроверять, чтобы назвать событие фактом. На этой идее предлагается решение — использовать Anti-Corruption Layer (ACL), для фильтрации «шумов» в событиях, с чем поможет read model (из EventStorming). Далее автор объясняет как реализовать подобную концепцию используя фантомные записи (данные, изначально пустые и которые постепенно заполняются). А в конце приводятся ситуации, когда подход сработает и когда могут возникнуть проблемы. #events #event_ordering