System Design World

🔜 Прощай, Ingress-nginx. Да здравствует Gateway API! ➕ Балансировка, маршрутизация и единая точка входа - без этого сложно представить и решение System Design задачи, и архитектуру реального сервиса. Особенно когда у нас Kubernetes со своими подами, которые то и дело умирают и возрождаются из пепла. 🏆 Теперь в этом запутанном облачном мире балом правит Gateway API. Приглашаю на встречу, чтобы на практике разобраться: ⚫️ чем маршрутизация Gateway API отличается от Ingress ⚫️ как выбрать контроллер ⚫️ как установить Gateway API в Managed Kubernetes ⚫️ как настроить безопасное подключение через TLS-сертификат Когда: 23 июля в 17:00 Кто ведёт: Старший SRE-инженер MWS Cloud Евгений Макеев ☺️ Будет полезно для DevOps, платформенным инженерам и разработчикам. Регистрация - клик.

💻 3D System Design. Запись 🎮 В игровом стиле прошлись по базе System Design. 🔘Взяли задачу - проектирование маркетплейса. 🔘Обсудили контекст. 🔘И пошли в симулятор 🎮 💡 К примеру, выкручиваем больше write трафика - больше клиентов делают заказы. Больше search - полнотекстовый поиск. Последовательно проектируем систему и обсуждаем популярные System Design Паттерны. 👀 Смотреть здесь - youtube.

3D System Design с Yet Another Analyst ☺️ Upd. Лампово посидели, спроектировали маркетплейс в симуляторе. Запись будет у Андрея. Картинки с вебинара в комментариях👌

💻 System Design: что такое CDC В прошлом посте мы разобрали CQRS на примере booking-сервиса. У нас была схема: 🫰 Админ обновляет данные номера в Postgres. 🔍 Пользователь ищет номера через ElasticSearch. Между ними есть важная часть: Postgres -> CDC -> ElasticSearch CDC - Change Data Capture. Перевожу для себя так - Захват Изменяющихся Данных Если просто - CDC позволяет отследить изменения в базе данных и передать их дальше в другую систему. CDC отвечает на вопрос: «Как изменения из source of truth доезжают до read model?» В нашем примере: Postgres - source of truth. ElasticSearch - read model для быстрого поиска. CDC - механизм доставки изменений между ними. ❓ Как реализовать эту концепцию? Один из способов реализовать CDC - outbox pattern. Идея: Когда сервис обновляет данные в Postgres, он в той же транзакции записывает событие в отдельную таблицу, называемую outbox. Например: ➡️ Обновили цену номера в таблице rooms. ➡️ В этой же транзакции записали событие room_price_updated в таблицу outbox_events. ➡️ Отдельный worker читает outbox_events. ➡️ Worker отправляет изменение дальше. Почему это удобно? ➡️ Потому что изменение данных и запись события происходят атомарно. Мы избежим ситуации, когда: ➡️ Данные в Postgres обновились. ➡️ А событие для ElasticSearch потерялось. 👍 Плюсы outbox pattern: 🤎 Надёжность: данные и событие записываются в одной транзакции. 🤎 Можно контролировать формат события. 🤎 Хорошо подходит для бизнес-событий: RoomUpdated, PriceChanged, BookingCreated. 🤎 Можно добавить retry, статус обработки и dead letter queue. Минусы: Давайте опишем в комментариях 👍 Итог: CDC - это способ доставить изменения из source of truth в другие системы. А outbox pattern - это один из практичных способов сделать такую доставку надёжнее. Цена - больше инфраструктурной логики и больше ответственности за обработку событий. Больше про паттерн: 🔘50 оттенков Transactional Outbox - Денис Цветцих 🔘Transaction Outbox под нагрузкой: как не потерять ни одного события при 100k+ RPS - Олег Мифле 🔘Outbox pattern для System Design Интервью - моя статья

3D System Design с Yet Another Analyst ☺️ А что если количество запросов вырастет в 10 000 раз? - популярный вопрос в конце System Design Интервью. А давайте проверим! 😊 🔥 С Андреем Бураковым из Yet Another Analyst спроектируем систему и дадим жаркой нагрузки!👨‍💻 Когда? Во вторник(14.07.26) в 19:00 Где? По ссылке на канале. Будет ближе к старту ☑️

💻 System Design: CQRS на примере booking-сервиса Допустим, мы проектируем сервис бронирования номеров. Кейс: 🔘Админ обновляет информацию о номере в Postgres 🔘Пользователь ищет номера через ElasticSearch 🎯 Получаем следующую схему: Postgres является source of truth. Храним основную информацию: номер, отель, цену, описание, доступность. ElasticSearch в нашей кейс - это read model. Нужен для быстрого поиска: фильтры по городу, датам, цене, удобствам, рейтингу и текстовому описанию. Таким образом получаем CQRS-схему: Запись идёт в одну модель Чтение из другой. Но в архитектуре не бывает идеального решения. Чем жертвуем здесь? 🟢Админ может поменять цену в Postgres, а пользователь ещё несколько секунд будет видеть старую цену в поиске. 🟢Или номер уже стал недоступен, но всё ещё отображается в выдаче. Потому что данные в ElasticSearch обновляются не мгновенно. И всё это из-за replication lag. 💡 Поэтому в такой архитектуре важно заранее решить: ➡️ какие данные можно показывать с задержкой; ➡️ какой лаг допустим для бизнеса: 1 секунда, 10 секунд, минута; ➡️ что делать, если пользователь выбрал номер из устаревшей выдачи; ➡️ нужно ли перед бронированием перечитывать актуальные данные из Postgres; ➡️ как мониторить задержку между Postgres и ElasticSearch; ➡️ как объяснять пользователю, что цена или доступность могли измениться. ✍️ Workaround Использовать ElasticSearch для поиска, но перед финальным бронированием всегда проверять актуальную цену и доступность в Postgres. То есть ElasticSearch отвечает на вопрос: «Что примерно подходит под запрос пользователя?» А Postgres отвечает на вопрос: «Можно ли это действительно забронировать прямо сейчас?» 2️⃣ Таким образом мы решили две задачи: 1) Улучшаем user experience - пользователь может искать номера по разным параметрам и текстовым запросам 2) Перед бронированием показываем финально актуальные данные. Итог CQRS (Command Query Responsibility Segregation) позволяет разделить обновление и чтение данных, чтобы эффективнее реализовывать разные сценарии работы системы. А что получает бизнес? => Быстрый сервис. => Удобный поиск. => Корректное бронирование. => Довольные пользователи. => profit 🚀

💪 Бодро начинаем неделю! Посылаю заряд хорошего настроения и продуктивного состояния 🔥

😍 Saint TeamLeadConf 2026 После HighLoad++ пришло время моей архитектурной каты на TeamLeadConf - той самой конференции, видео с которой засматривал до дыр в бытность тим/тех лида в Сбере. Пользуясь возможностью личного присутствия, в этот раз ходил на воркшопы. ➡️ "Черная Риторика" на работе. Встречали такую? 🔘 В этом воркшопе разбились по группам для отработки сценариев. Нам досталась история технаря, который хочет уделить время рефакторингу, а менеджеру нужны новые фичи! 🔘 Фразы из такой риторики лились как из рога изобилия. Нужно было их находить и относись к категориям, а потом самим разыгрывать сценки. Как парировать? Сначала нужно осознать, что коллега сказал дичь пошёл не туда. Затем возвращаться в исходное русло обсуждения проблемы. 👨‍🎓 Под конец я был в роли обороняющегося - с командой, которую менеджер хочет вывести из удалёнки, потому что сейчас такой тренд в компании. Я парировал тем, что У нас интроверты, топ-перформеры и мы делаем нужные бизнесу крутые фичи лучше других 🤩 Время и аргументы против моей позиции кончились. Команда осталась на удалёнке 🕯 🚀 Свет, камера, мотор! Популярность воркшопов зашкаливала. Под кату на всякий случай сделал больше задач, поставили больше столов. И правильно сделали! Казалось бы, менеджерская конференция, а архитектурная ката зашла на ура) Посетили в том числе мои знакомые: 🔘Иван Садовой - Техлид бизнес-юнита Авиа в Туту 🔘Александр Межов - ИТ-архитектор. Повезло с моим куратором - архитектором Русланом Сафиным. Он же был соведущим и вторым судьёй. Если хотите провести кату в своей компании, пишите! Опыт есть! ☺️ 💡 Были ещё интересные доклады В том числе организационные про AI. Думаю сделать встречу, чтобы поделиться текущими трендами и тем, что взял для себя. Семейные гуляния Мы оказались в Санкт-Петербурге на праздник "Алые Паруса"! 🔤 Были в Казанском Соборе, на перекрытом Невском(так необычно!), Спасе на Крови(наконец-то!). А после из гостиницы даже увидели праздничный фейерверк. Питер в этот раз попал в ❤️