ИТ-архитектура

https://www.youtube.com/live/N_n3AQtrfEU?si=h3IaD4Avi-LFgGMi

Technology Radar за апрель 2026 Почитал свежий Technology Radar. Если коротко: мы входим в эру агентов, с одной стороны это дает много преимуществ, с другой большая головная боль для инженеров. Вот главные мысли: • Инструменты-однодневки. Раньше софт писали команды, теперь - один разработчки с ИИ-помощником. Новых решений море, но они часто сырые и бросаются авторами через месяц. Сложно понять, что реально внедрять, а что хайп "на коленке". • Когнитивный долг. Это самая опасная штука. ИИ генерит код пачками, мы его вставляем, но перестаем понимать, как он работает. Если не вникать в суть, проект превращается в black box, который невозможно дебажить. • Вопросы безопасности. Самые полезные агенты - те, у кого есть доступ ко всему (базам, почте, серверам). Но защиты от зловредных промптов до сих пор нет. Дать агенту доступ к production сегодня - это как пустить ребенка за руль гоночного болида. • Агентов нужно держать под двойным контролем: На входе: четкие инструкции и лимиты (Agent Skills). На выходе: жесткие авто-тесты и линтеры. Если код не проходит тесты, агент должен сам его переделывать, пока не станет идеально. Резюме Мы переходим от «командных топологий» к «агентским топологиям». Скорость без дисциплины умножает стоимость владения кодом. Сейчас время осторожности и жестких инженерных практик (чистый код, тесты, архитектура), а не слепого доверия автопилоту. Ссылка: https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2026/04/tr_technology_radar_vol_34_en.pdf #ai #software_engineering #techradar На связи с вами @itarchitecture

Dual Write Problem Dual Write Problem (проблема двойной записи) возникает, когда две или больше операций должны быть согласованными, но выполняются в разных системах или базах данных. Типичный пример — запись данных в базу и публикация события в event broker. Что произойдёт, если приложение упадёт после сохранения данных, но до отправки события? Транзакции здесь не работают, потому что задействованы разные системы. Если не координировать такие операции, неизбежно возникнут проблемы: одна операция выполнится успешно, а другая — нет. Есть два стандартных решения. 1. Использование Change Data Capture (CDC) После записи данных в базу механизмы CDC отслеживают изменения. Инструмент или сервис CDC затем читает эти изменения и публикует их как события в event broker. Преимущества: • Нет ответственности на уровне приложения: приложению не нужно публиковать события — это делает CDC-инструмент • Надёжность: CDC тесно связан с базой данных, поэтому все зафиксированные транзакции в итоге будут обработаны и опубликованы. Компромисс: Настройка и поддержка CDC-инструментов добавляет операционной сложности. 2. Паттерн Outbox Паттерн Outbox сохраняет события в специальную таблицу outbox в той же транзакции, в которой изменяются данные. Затем отдельный асинхронный процесс читает записи из этой таблицы и публикует события в event broker. Преимущества: • Атомарность: изменение данных и запись события происходят в одной транзакции — либо оба фиксируются, либо оба откатываются. • Eventual Consistency (конечная согласованность): события всё равно будут опубликованы, даже если первая попытка не удалась. Компромисс: Появляется дополнительная "обвязка": * таблица outbox * процесс, который читает её и публикует события. Важно помнить Без распределённых транзакций мы можем строить только системы с конечной согласованностью (eventual consistency). #pattern #eventual_consistency #cdc На связи с вами @itarchitecture

День из жизни Solutions Architect #fun

Как внедряли DDD в Яндекс360 - Что такое DDD и зачем он нужен? - Какой книгой лучше всего начать знакомство? - Как DDD сочетается с TDD, BDD и Event-Driven? - Почему DDD сложно внедрять и как это делать правильно? - Будущее DDD и его минусы #podcast #ddd #softwarearchitecture На связи с вами @itarchitecture https://pca.st/episode/0e0ed0d0-5f64-4be0-88eb-443496965388

🎬 Архитектура предпросмотра видео в Netflix Когда вы наводите курсор на таймлайн Netflix, вы видите, как выглядит сцена в этот момент времени. Как это устроено? Загружает ли Netflix весь фильм заранее? Если бы это было так, фильм продолжал бы воспроизводиться даже после отключения интернета. Netflix достигает плавного предпросмотра таймлайна (технически это называется Trick Play или Scrubbing) с помощью продуманной техники оптимизации изображений, называемой Sprite Sheets или Storyboards. Они не загружают реальный видеофайл при наведении. Вместо этого сервер отдает отдельный, легковесный набор статических изображений. Ниже — архитектурный разбор того, как это работает. 🏗️ 1. Предварительная обработка Когда фильм или эпизод загружается на серверы Netflix, он проходит через конвейер кодирования. Пока обрабатывается видео высокого качества, параллельно запускается отдельный процесс специально для предпросмотра таймлайна: - Извлечение кадров: Система извлекает кадры низкого разрешения с заданным интервалом, например каждые 1, 3 или 10 секунд. - Сшивание (магический шаг): Вместо сохранения тысяч отдельных файлов изображений, что потребовало бы тысячи медленных сетевых запросов, система сшивает эти кадры в один большой файл изображения, называемый Sprite Sheet. - Визуальный пример: Представьте один JPEG-файл в виде сетки 5×5, содержащей 25 маленьких скриншотов. 🗂️ 2. Индексация Вместе со спрайт-листом Netflix генерирует небольшой текстовый файл, часто в формате WebVTT или собственного JSON. Этот файл выступает в роли карты и говорит видеоплееру: «Если пользователь навел курсор на таймкод 10:05, возьми файл sprite_sheet_3.jpg и покажи прямоугольник, начинающийся с координат x=200, y=0». 📺 3. Клиентский опыт Когда вы открываете фильм, ваше устройство сразу загружает этот небольшой файл метаданных. - Наведение: Вы перемещаете курсор к отметке 25 минут. - Вычисление: Плеер смотрит в карту метаданных, чтобы определить, в каком спрайт-листе находится кадр для 25-й минуты. - Загрузка (lazy load): Если нужный спрайт-лист еще не загружен, плеер скачивает только этот конкретный файл изображения. - Отображение: С помощью CSS или Canvas плеер показывает «окошко», скрывая весь спрайт-лист, кроме нужной ячейки. Преимущества 🚀 Скорость: Загрузка одного большого изображения значительно быстрее, чем загрузка 50 маленьких файлов. ⚡ Низкая задержка: Так как изображения заранее загружены или находятся в кэше, предпросмотр появляется мгновенно, даже если основное видео буферизуется. 📉 Экономия трафика: Превью имеют очень низкое качество, обычно около 160px по ширине. Из-за малого размера и кратковременного просмотра сильное сжатие практически незаметно. #streaming #performance #media На связи с вами https://t.me/itarchitecture

https://youtu.be/MzNRbpF9pEU?si=xCxdS-mDzH1dvnkh

Как выбрать базу данных и не пожалеть: полвека экспериментов и личный опыт https://youtu.be/B1wE8eusMIo?si=580QtdvfpwyirE-M

Если проект растёт, а архитектура кажется стабильной только на первый взгляд, самое время разобрать типовые ошибки, которые допускают даже опытные команды. Приходи на новый сезон онлайн-конференции Podlodka Techlead Crew, посвященный архитектурным антипаттернам. На конференции будет дискуссия как отличать симптомы от причин, не наступать на грабли и выбирать работающие способы изменений. Что в программе? 🚀От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито). 🤖AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк). 🏗️Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services). 💪🏼Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World). 🗓️13-17 октября — недельная концентрация пользы, практики и классный нетворк. Присоединяйся! Подробности и билеты: https://podlodka.io/techcrew А промокод «itarchitecture» даёт скидку еще в 3500 тенге или 500 руб🥳

Задержки (latency) — смерть от тысячи порезов Исправляем. Вот 5 проверенных способов ускорить систему: 1. Оптимизируйте запросы к БД Один кривой запрос легко добавит +500 мс. Умножьте на тысячи запросов в секунду — получите тормоза по всей системе. 🚫 Не пишите SELECT * 🗂️ Добавляйте нужные индексы 🔄 Устраняйте N+1-запросы 📊 Измеряйте, а не гадайте (EXPLAIN, профайлеры) 2. Сократите сетевые прыжки Каждый переход: A → B → C → D добавляет лишние миллисекунды. 🧩 Объединяйте мелкие сервисы 🏗️ Используйте backend-for-frontend (BFF) 3. Кэшируйте горячие данные Если данные редко меняются — не тратьте время на их повторный запрос. 💾 Сессии, каталоги, конфиги держите в кэше ⚠️ Просроченный кэш неприятен, но отсутствие кэша хуже 4. Батчите и параллельте запросы Латентность накапливается, если гонять по одному запросу. 🔗 Объединяйте запросы в один батч 🏎️ Запускайте их параллельно 📉 Меньше сетевых походов → быстрее ответ 5. Уменьшайте объём передаваемых данных Не возите «грузовик» данных, когда нужен «рюкзак». ✂️ Убирайте ненужные поля 🗜️ Сжимайте ответы 📑 Используйте пагинацию 🖼️ Оптимизируйте изображения ⚡ Скорость — это не фича. Это фундамент UX. Медленно = плохо. Быстро = довольный пользователь. #performance #latency #optimization На связи с вами https://t.me/itarchitecture

Применимо к деятельности архитектора “У меня есть три наставника. Когда я сталкиваюсь с проблемой и мне нужна их помощь, прежде чем обратиться к ним я сначала стараюсь как можно лучше описать свою ситуацию. Кратко излагаю контекст, саму проблему, опции на столе и свои размышления по каждой из них. Стараюсь сделать это максимально сжато, чтобы не тратить их время. Прежде чем отправить им сообщение, я пытаюсь предсказать, что они скажут. Затем возвращаюсь к тексту и обновляю его, чтобы заранее учесть их замечания. После этого я снова пытаюсь предсказать, что они скажут. В этот раз, опираясь на то, что они говорили ранее, и то, что я знаю о их философии и ходе размышлений. Пройдя весь этот процесс, я понимаю, что мне не нужно их беспокоить, т.к. решение становится очевидным. Никто из них не знает, что они мои наставники”. - Дерек Сиверс

Просто retries — не про устойчивость, нужно добавить таймауты, backoff, jitter и идемпотентность Retries помогают тебе, но могут добить соседний сервис. Retries не делают систему надёжной, если ты не добавил: - таймауты - backoff - jitter - идемпотентность Без них retries не решают проблему — они её усиливают. Базовый набор: 1️⃣ Таймауты Ждать вечно — ловушка. Зависший запрос жрёт ресурсы: - потоки - память - подключения к БД. Чем дольше висит — тем хуже всем. 2️⃣ Backoff (повтор с увеличивающимися задержками) Не лупи по падающему сервису. Retries должны быть с паузами. Дай системе отдышаться. 3️⃣ Jitter (случайная задержка) Если все ретраят одновременно — это давка. Добавь случайность. Распредели нагрузку. Спаси бэкенд. 4️⃣ Идемпотентность Некоторые API имеют сайд-эффекты — отправка писем, списания с карт. Если повторить такой запрос — будет беда. Сделай так, чтобы одинаковый запрос давал один и тот же результат. Без дублей. Retries должны работать вместе с системой, а не против неё. #resilience #highload На связи с вами https://t.me/itarchitecture

ОФИЦИАЛЬНО: ЗАПУСК AEA KAZAKHSTAN CHAPTER 🇰🇿 Друзья, с гордостью сообщаю: Казахстан официально присоединился к глобальному сообществу архитекторов предприятия (Association of Enterprise Architects – AEA Global). Подписано соглашение о запуске Kazakhstan Chapter. Мы стали частью международной сети архитекторов, объединяющей экспертов из более чем 100 стран мира. Кто мы? Мы - профессиональное сообщество архитекторов, стратегов и ИТ-лидеров, которые: - Строят архитектуру цифрового будущего - Делятся практиками и международными стандартами (TOGAF, ArchiMate, DDD, System Design & etc.) - Создают площадку для обмена знаниями, развития карьеры и нетворкинга Офицеры Казахстанского отделения: Председатель: Даурен Досымбек, Solution Architect, PhD researcher (https://lnkd.in/dVK7-2qj) Основные учредители: 1. Жанат Нурбекова (https://lnkd.in/d9yuybg8) 2. Александр Полоротов (https://lnkd.in/dT__U3jn) 3. Виталий Тренкеншу (https://lnkd.in/dEXCEZtw) 4. Давид Туганов (https://lnkd.in/dRhThpsY) 5. Сапарбек Досымбек (https://lnkd.in/dxf2SfZ8) 6. Даулет Бешеев 7. Димаш Тореханов 8. Марат Сагалов (https://lnkd.in/dYTXr8mC) 9. Айжаркын Акпаров (https://lnkd.in/dnCSAnJV) 10. Акарыс Мусабек (https://lnkd.in/dVgVHAfB) Что дальше? В ближайшее время: - Запуск сайта и социальных страниц - Онлайн-встречи и митапы (в т.ч. с международными спикерами) - Образовательные инициативы, менторство и сообщества по интересам - Открытый диалог — для архитекторов, CTO, BA, IT-стратегов и не только Приглашаем присоединиться к нашему пути. Будем вместе формировать сильное архитектурное мышление в Казахстане и показывать миру, что у нас есть чему научить. Добро пожаловать! Будущее начинается с архитектуры. Ссылка на группу Chapter https://t.me/+Oz5SUU23GtY3MWEy

Что такое MCP — Model Context Protocol? Простыми словами — это «USB-C для ИИ». ⚙️ В чём суть MCP? Так же как USB-C стандартизировал подключение устройств (питание, передача данных и т.д.), MCP стандартизирует подключение ИИ-агентов к внешним источникам данных и инструментам. 👉 До MCP каждый сервис или API имел свои уникальные протоколы и методы. MCP заменяет этот зоопарк единым, универсальным интерфейсом. 🧩 Как это работает? MCP-сервер — это совместимый инструмент, который может: - сообщить, какие функции он предоставляет - выполнить действие по запросу ИИ-агента MCP-клиент (агент) умеет: - автоматически обнаруживать, какие возможности есть у сервера - вызывать их через единый протокол 📚 Важно: MCP — это не только про действия, но и про знания. Например: Один MCP-сервер может быть доступом к внутренним документам компании. Другой — отправлять письма или обновлять записи. Для агента всё это — «инструменты», просто одни возвращают данные, другие выполняют действия. 🔌 Кратко: Подключаешь MCP-сервер — и агент сразу видит, что он умеет. Никаких дополнительных настроек, инструкций или хардкода. Всё по стандарту. #ai #ai_agent #mcp На связи с вами https://t.me/itarchitecture

https://www.youtube.com/watch?v=Q3kCFuaCe0I

Backend for Frontend (BFF) Сегодня, когда повсеместно используются микросервисы, облачные архитектуры и множество различных клиентских устройств — от веб-приложений до мобильных приложений и IoT — использование универсального единого backend часто не приносит ожидаемых результатов. Именно здесь на помощь приходит архитектура BFF, предлагая более точечный и эффективный подход. 1. Что такое BFF? 💡BFF представляет собой отдельный backend-слой для каждого типа клиентского интерфейса: мобильного приложения, веб-приложения или «умного» устройства. Каждый слой предоставляет только те данные и функциональность, которые действительно необходимы конкретному клиенту. Основные преимущества BFF: 🔹 Объединение запросов к различным сервисам в единый API, понятный клиенту. 🔹 Форматирование данных в удобный для конкретного интерфейса вид. 🔹 Разгрузка основного backend-а от логики, специфичной для определённых клиентов. Разделение ответственности помогает упростить разработку и сделать пользовательский опыт более адаптированным к каждому устройству. 2. Почему BFF востребован: ✨ Индивидуальный пользовательский опыт: Каждый клиентский интерфейс получает только те данные, которые ему действительно нужны, без избыточных или недостаточных запросов. ⚡ Повышение производительности: Снижение количества ненужных запросов к API делает приложения быстрее и удобнее. 🤝 Упрощение разработки: Различные команды могут работать над своими BFF независимо друг от друга, минимизируя узкие места и задержки. 🔒 Дополнительный уровень защиты: Хотя основная безопасность часто обеспечивается отдельными механизмами, BFF может выполнять дополнительную фильтрацию данных, управление доступом и валидацию запросов. 3. Когда имеет смысл использовать BFF: 📱 Приложения для разных платформ: Если ваше приложение должно работать с веб-интерфейсами, мобильными устройствами и IoT-устройствами, каждая из этих платформ может иметь свои уникальные потребности. BFF позволяет учесть эти различия и предоставить каждому клиенту оптимальные данные. 🔗 Упрощение взаимодействия с микросервисами: BFF упрощает сложные запросы, объединяя данные из разных backend-сервисов в единый ответ. 🔧 Модернизация устаревших API: BFF может выступить в роли адаптера, скрывая сложные или неудобные аспекты старых систем от современных интерфейсов. 4. Когда BFF может не понадобиться: Если у вас небольшой проект с ограниченным числом клиентских интерфейсов, где все они имеют схожие требования, BFF может оказаться ненужным. В таких случаях избыточная сложность и дополнительные затраты на разработку могут перевесить преимущества. 5. Лучшие подходы для успешного использования BFF: ✔️ Минимизируйте логику: Позвольте основным сервисам обрабатывать сложные вычисления, а BFF сосредоточьте на адаптации данных и маршрутизации запросов. ✔️ Внедряйте кэширование: Повышайте производительность, особенно при медленных сетях. ✔️ Централизуйте обработку ошибок: Сделайте ответы об ошибках единообразными для всех клиентских платформ. ✔️ Защитите BFF: Используйте проверку доступа, валидацию данных и управление скоростью запросов. 6. Примеры из практики 🎥 Netflix: Оптимизирует ответы для мобильных пользователей, предоставляя облегчённые данные, а для настольных приложений предлагает более богатые функции. 🎵 Spotify: Обеспечивает согласованную работу данных на телефонах, планшетах и умных динамиках, предоставляя удобный и стабильный пользовательский опыт. 7. Преимущества BFF: 🌟 Создание приложений с высокой скоростью работы и персонализацией. 🌟 Упрощение сложных процессов взаимодействия с backend-сервисами. 🌟 Повышение масштабируемости и обеспечение дополнительного уровня безопасности. #bff #backend #frontend На связи с вами https://t.me/itarchitecture

https://rutube.ru/video/ce5cc1cbadcc6d82d435ff9d197ca201/

https://youtu.be/slABtpVPHNI?si=lecgceZPp9A06vjO

#podcast Бережливый архитектор https://pca.st/episode/26b45978-5f22-48fb-a99e-cf11646659b7

Podlodka Techlead Crew – онлайн-конференция для техлидов и опытных инженеров, которая пройдет с 14 по 18 октября. Тема сезона – "Проектируем надёжность". В программе много всего интересного, и вот несколько примеров: - как закладывать надёжную архитектуру на старте, используя механизмы самоисцеления и повторных попыток; - публичное собеседование техлидов на понимание важности надёжности систем; - как мелкие проблемы и человеческие ошибки могут стать причиной крупных сбоев через месяцы эксплуатации; - как Feature Toggles помогают гибко управлять функционалом и снижать риски. А еще архитектурная ката по проектированию надежной системы. https://podlodka.io/techcrew Доступна скидка для подписчиков по промокоду: techlead_crew_7_k08mgg