Хвост инженера

Автор: Максим Денушев (Точка) · Golang Channel

Максим Денушев работает в банке Точка. Доклад с GolangConf 2024, 31 минута. API Gateway — компонент, через который проходит весь трафик платформы. Переписать его — значит заменить двигатель у летящего самолёта: система должна оставаться доступной, а пользователи не должны заметить, что что-то происходит.

Главная сложность такой задачи не техническая, а операционная. Выбрать новый стек и написать код — это меньшая часть работы. Настоящий вызов — как организовать переход так, чтобы в каждый момент времени система работала корректно для всех клиентов. Денушев разбирает подход, который команда применила: постепенное перемещение трафика через новый Gateway параллельно со старым, профилирование под реальной нагрузкой, работа с проблемами обратной совместимости, которые обнаруживаются только когда через систему идут реальные данные. Это не история успеха без шрамов — доклад честный о том, с какими проблемами они столкнулись и что их не предусмотрели заранее.

Кому смотреть: backend-инженерам и архитекторам, которые стоят перед задачей замены критического инфраструктурного компонента — не только Gateway, но и любого, через который проходит весь трафик.

Из этого можно взять в работу: если вы планируете значительное изменение инфраструктурного компонента — составьте список всего, что через него проходит, и определите, какие клиенты заметят изменение первыми. Это первый шаг к плану миграции, который не ломает продакшн.

Автор: Дмитрий Самохвалов · HighLoad++ Channel

Доклад с HighLoad++ 2024, 49 минут. Kubernetes великолепно работает внутри себя. Проблемы начинаются на границе: когда поды должны обращаться к legacy-сервисам вне кластера, а legacy-системы — к подам. Эта граница существует у большинства компаний, которые переходят на Kubernetes постепенно, а не заново строят всё с нуля.

Самохвалов разбирает конкретные конфигурации и паттерны: как работает сетевая модель Kubernetes (flat network, каждый под получает IP) и почему она не совпадает с тем, чего ждёт legacy-окружение; как CNI-плагины (Calico, Cilium, Flannel) по-разному решают задачу связности; как настроить BGP-пиринг между кластером и существующей сетевой инфраструктурой; почему NodePort и LoadBalancer — это не решение, а костыль, который работает до определённого масштаба. Это доклад не про «установите Kubernetes», а про то, что происходит когда старая и новая инфраструктура должны сосуществовать в одной сети.

Кому смотреть: DevOps- и SRE-инженерам, занимающимся миграцией на Kubernetes в организациях с существующей инфраструктурой — особенно там, где legacy не уйдёт в ближайшие годы.

Из этого можно взять в работу: если у вас поды Kubernetes обращаются к legacy-сервисам через ExternalName Service или захардкоженные IP — это временное решение, которое не масштабируется и не обеспечивает failover. Доклад показывает, как это сделать правильно.

Автор: Listen IT · Listen IT

Видео Listen IT, 9 минут. Canary deployment и Blue-Green — две стратегии выката, которые решают одну задачу разными способами: как выпускать новые версии без того, чтобы весь трафик сразу шёл на непроверенный код.

Canary deployment — это постепенный выкат: сначала 1–5% пользователей получают новую версию, остальные работают со старой. За это время смотрят на метрики: error rate, latency, конверсии. Если всё хорошо — процент растёт. Если что-то ломается — откатить стоит секунд, а не часов. Название идёт от шахтёрской практики: канарейки чувствовали токсичный газ раньше людей. Небольшой процент пользователей — первые, кто обнаруживает проблему, пока большинство ещё на безопасном коде. Это принципиально другой разговор о надёжности: не “как сделать, чтобы не сломалось”, а “как сделать, чтобы поломка затронула минимум людей и откатилась быстро”.

Кому смотреть: разработчикам и DevOps-инженерам, у которых релиз — это страшное событие раз в неделю с ручным smoke-тестингом. И тем, кто хочет перейти к continuous delivery, но не понимает, с чего начать с точки зрения безопасности выката.

Из этого можно взять в работу: посмотрите на последний релиз в вашей системе. Сколько времени заняло бы обнаружение проблемы, если бы она появилась? Если больше 15 минут — у вас нет canary, и риск каждого релиза выше, чем должен быть.

Автор: Михаил Жилин · HighLoad++ Channel

Доклад с HighLoad++ 2024, 50 минут. PostgreSQL — база, которую хорошо знают и любят. Но поведение под нагрузкой — это другая тема: здесь включаются механизмы, которые в обычной работе не видны и в документации описаны скромно.

Жилин разбирает аномалии, которые проявляются именно под нагрузкой: как MVCC-механизм начинает накапливать мёртвые версии строк быстрее, чем autovacuum успевает их убирать; как это влияет на размер таблиц и производительность запросов; какие блокировки возникают там, где их не ждёшь; как connection pool ведёт себя при спайках и почему «просто увеличить max_connections» решает одну проблему и создаёт две новых. Доклад не обзорный — это конкретный производственный опыт с цифрами и конфигурациями.

Кому смотреть: разработчикам и DBA, которые эксплуатируют PostgreSQL под реальной нагрузкой и хотят понять, почему база «начала тормозить» — и особенно тем, кто ещё не сталкивался с bloat и autovacuum lag, пока они не случились в продакшне.

Из этого можно взять в работу: посмотрите на размер ваших самых активно обновляемых таблиц через pg_stat_user_tables — n_dead_tup / n_live_tup. Если соотношение высокое, у вас есть bloat, который под нагрузкой превратится в деградацию производительности.

Автор: Андрей Аксенов · Podlodka Podcast

Андрей Аксенов — автор поискового движка Sphinx и человек, который писал собственные хэш-таблицы тогда, когда это ещё было нормальной практикой. Выпуск Podlodka #464 — не обзор структур данных, а разговор с человеком, который знает, где у хэш-таблиц болевые точки.

Хэш-таблицы — та структура данных, которую все используют и почти никто не понимает глубоко. Большинство разработчиков знают про O(1) в среднем и помнят что-то про load factor «меньше 0.75». Аксенов разбирает, откуда берутся эти числа, почему они не универсальны, и что реально происходит с производительностью, когда таблица растёт. Центральный тезис: поведение хэш-таблицы определяется не только алгоритмом, но и характером данных и паттерном доступа — и одна реализация не может быть одинаково хороша везде.

Разговор про open addressing особенно ценен: это техника, которая лежит в основе многих стандартных библиотек, но редко объясняется на уровне «почему именно так, а не иначе».

Кому смотреть: разработчикам, которые хотят понимать, что происходит внутри HashMap в их стандартной библиотеке, и тем, кто сталкивается с перформанс-проблемами в коде, который «должен работать быстро».

Из этого можно взять в работу: в следующий раз, когда выбираете или конфигурируете хэш-таблицу, спросите себя: какой у нас паттерн доступа — много reads или много writes, известен ли размер заранее, однородны ли ключи. Ответы на эти вопросы определяют выбор лучше, чем любой дефолтный load factor.

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. C4 — архитектурная нотация, созданная Саймоном Брауном как ответ на две типичные проблемы: диаграммы, которые непонятны никому кроме их автора, и схемы, которые устаревают быстрее, чем успевают быть прочитанными.

Большинство архитектурных диаграмм страдают одним и тем же пороком: непонятно, для кого они нарисованы. Схема, адресованная топ-менеджменту, содержит детали реализации, интересные только разработчикам. Схема для разработчиков — слишком крупная, чтобы из неё понять что-то конкретное. C4 решает это через явную иерархию четырёх уровней: Context (система и её окружение для нетехнической аудитории), Container (приложения и базы данных, из которых состоит система), Component (модули внутри одного контейнера) и Code (диаграммы классов, нужны редко). Каждый уровень отвечает на разный вопрос и адресован разной аудитории — и это не абстрактная теория, а конкретный инструмент против диаграмм, которые не читает никто.

Кому смотреть: разработчикам и техлидам, которым нужно объяснять архитектуру коллегам с разным уровнем технической подготовки — и всем, кто хочет перестать рисовать схемы “для галочки”.

Из этого можно взять в работу: нарисуйте C4 Context-диаграмму вашей системы — один прямоугольник в центре, несколько снаружи. Если не можете объяснить за пять минут нетехническому коллеге, что происходит на этой схеме — схема не работает. C4 Context — именно для этой цели.

Автор: Владислав Танков · Podlodka Podcast

Владислав Танков — директор по AI в JetBrains. Это второй его выпуск на Podlodka (#452): первый (#444) был про внутреннее устройство LLM на уровне трансформеров и аттеншенов. Этот — про то, что происходит, когда модель нужно не просто запустить, а запустить в продакшне под реальной нагрузкой.

Большинство разговоров про LLM в продакшне сводятся к «берём OpenAI API и готово». Танков рассказывает про другой класс задач: когда API не подходит — из-за данных, задержки, стоимости или политики безопасности — и нужно думать об инфраструктуре самому. Локальный инференс vs облачный — это не просто вопрос цены, это вопрос контроля над latency, privacy и зависимостью от внешнего провайдера. В JetBrains этот выбор делается для каждого продукта отдельно, и критерии нетривиальны.

Кому смотреть: инженерам и архитекторам, которые строят или планируют строить продукты поверх LLM и хотят понять инфраструктурную сторону вопроса — не теорию трансформеров, а что конкретно потребляет память, откуда берётся latency и где узкое место при масштабировании.

Из этого можно взять в работу: если вы сейчас используете LLM только через API — составьте список требований к задержке, приватности данных и стоимости для вашего конкретного use case. Это займёт час, но может изменить архитектурное решение.

Автор: Александр Данковцев · HighLoad++

Александр Данковцев — Lead Engineer команды Antimonolith в Авито. Команда занимается тем, что помогает сотням сервисов взаимодействовать друг с другом не хаотично, а по правилам. Доклад с HighLoad++ 2024 — про API Gateway как ключевой элемент этой архитектуры.

API Gateway — одно из тех решений, которые выглядят просто («просто обратный прокси с маршрутизацией»), пока вы не начинаете масштабировать. В Авито тысячи микросервисов, сотни команд и постоянно меняющиеся API. Данковцев рассказывает, как Gateway эволюционировал от простого роутера до полноценного инфраструктурного продукта: с собственным языком конфигурации, валидацией, rate limiting, auth-интеграцией и observability. Ключевая мысль: когда Gateway становится платформой, а не конфигом nginx, он начинает требовать того же инженерного внимания, что и любой другой продукт — владельца, versioning, обратной совместимости.

Кому смотреть: архитекторам и техлидам, которые строят или унаследовали API Gateway в системе с более чем десятком сервисов — особенно тем, у кого роутинг пока «просто конфиг».

Из этого можно взять в работу: посмотрите на ваш текущий API Gateway как на продукт: есть ли у него владелец, changelog, способ добавить новый маршрут без ручного merge конфига? Если нет — вы уже несёте технический долг, который растёт с каждым новым сервисом.

Автор: Дмитрий Коваников · Podlodka Podcast

Дмитрий Коваников — Senior-разработчик в Bloomberg и практикующий Haskell-программист. Он приходит в разговор о конфигурационных языках не как DevOps, а как человек, который думает о типах и корректности программ.

YAML победил как конфигурационный формат не потому что хорош, а потому что лучше XML и JSON для человекочитаемых конфигов. Но у него есть фундаментальная проблема: он динамически типизирован и разрешает неявные преобразования. «Norway problem» — это не анекдот, а реальный баг: NO в YAML интерпретируется как булев false, и код страны Норвегии превращается в логическую ложь без единого предупреждения. TOML решает часть проблем, но не даёт ничего похожего на статическую проверку. Dhall — типизированный функциональный язык конфигурации — задаёт другой вопрос: а что, если конфигурация была бы верифицируема до деплоя?

Кому смотреть: backend-разработчикам и DevOps, у которых есть большие YAML-конфиги с логикой внутри — якоря, шаблоны, условия — и которые замечали, что ошибки в конфигурации бывает сложнее поймать, чем ошибки в коде.

Из этого можно взять в работу: найди самый большой YAML в своём репозитории и посчитай, сколько там логики — якоря, merge keys, шаблоны. Это ровно та часть, которую Dhall мог бы сделать верифицируемой.

Автор: Константин Осипов · Организованное программирование | Кирилл Мокевнин

Константин Осипов видел базы данных с нескольких сторон, которые большинству недоступны одновременно: core-разработчик MySQL, создатель Tarantool (в production у ВКонтакте и десятков других высоконагруженных систем), директор разработки в ScyllaDB, сооснователь PicoData.

Это не обзор технологий. Это взгляд изнутри на то, как устроен рынок СУБД — почему Postgres доминирует, что на самом деле произошло с NoSQL-хайпом и куда движется индустрия через десять лет. Версия Осипова отличается от того, что читаешь в статьях — потому что он строил эти системы, а не писал про них.

Особенно интересна часть про MySQL и Oracle: как выглядит сделка, если ты в ней не инвестор, а инженер, который писал этот код.

Кому смотреть: backend-разработчикам и архитекторам, которым интересно понять индустрию баз данных не через документацию, а через опыт людей, которые её создавали.

Из этого можно взять в работу: эволюция СУБД — это история о том, чьи интересы побеждали на каждом повороте. Понимание этого контекста меняет то, как выбираешь инструменты на следующие 10 лет.

Автор: Сергей Андржеевский · ScrumTrek

Сергей Андржеевский выступал на Ag;)eDays 2011 — одной из ранних российских Agile-конференций. Доклад старый, но вопрос, который он разбирает, не устарел: как работают XP-практики в условиях, когда команда разделена географически и работает на внешнего заказчика.

Офшорный проект — это специфический контекст. Разные часовые пояса, заказчик, который не сидит рядом, контрактная модель, которая создаёт стимулы скрывать проблемы, а не решать их. XP создавался для команды в одной комнате с заказчиком рядом. Андржеевский рассказывает, что из XP работает в офшорном контексте, что требует адаптации, а что — предположение, которое офшор разрушает принципиально. Центральный тезис: парное программирование и TDD в офшорном контексте — это не способ быстро работать, это способ поддерживать качество без прямого контроля. Заказчик не видит код — он видит результат. Дисциплина XP-практик создаёт доверие через предсказуемость результата.

Кому смотреть: тимлидам и менеджерам в распределённых командах, которые хотят понять, какие инженерные практики заменяют «управление через присутствие» в удалённом контексте.

Из этого можно взять в работу: если у тебя распределённая команда и ты используешь парное программирование — проверь, решаешь ли ты им задачу координации (кто что делает, где риски) или только задачу обучения. Это разные цели с разной оптимальной частотой сессий.

Автор: Владимир Протасов · Habr

Владимир Протасов — разработчик с опытом highload-систем, выступал на HighLoad++ 2016 с докладом об OpenResty. Доклад из тех, что не устаревают: OpenResty существует с 2009 года, но основная масса разработчиков по-прежнему думает о нём как о «Nginx с Lua» и недооценивает, что именно это означает.

OpenResty встраивает LuaJIT прямо в worker-процессы Nginx и даёт хуки на каждую фазу обработки запроса: до получения заголовков, после, перед отправкой ответа, при ошибке. Это не «скрипт, вызываемый Nginx» — это Lua, исполняемый с той же производительностью, что и сам Nginx, без форков, без HTTP-запросов к отдельному backend, без копирования тела запроса туда-обратно. Авторизация, rate limiting, трансформация ответов, маршрутизация на основе тела запроса — всё это можно делать без выхода из nginx-контекста.

Протасов разбирает конкретные паттерны: как подключить Redis через cosocket API (без блокировки event loop), как кешировать сессии, как писать обработчики для нестандартных протоколов. Это не «hello world на Lua в nginx», а production-архитектура.

Кому смотреть: backend-разработчикам, которые используют Nginx как reverse proxy и хотят перенести часть логики (auth, rate limiting, A/B-роутинг) ближе к трафику, не добавляя отдельный сервис.

Из этого можно взять в работу: если у тебя есть endpoint, который только проверяет token и проксирует запрос дальше — попробуй вынести проверку на уровень OpenResty. Latency упадёт, а отдельный auth-сервис в цепочке исчезнет.

Автор: Дмитрий Евдокимов · VK Cloud

Дмитрий Евдокимов — CTO Luntry, платформы безопасности для Kubernetes. Luntry строится поверх Kubernetes API, поэтому понимание KRM у него не теоретическое — это основа продукта. Доклад с VK Kubernetes Conference.

Kubernetes Resource Model — это абстракция, которую легко пропустить за привычными деплойментами и сервисами. Суть в том, что Kubernetes — это не оркестратор контейнеров, а universal control plane для управления любыми ресурсами. Всё, что можно описать как «желаемое состояние + текущее состояние + reconciler», может стать Kubernetes-ресурсом. Это означает, что KRM применима не только к подам, но и к облачным ресурсам, сетевым политикам, конфигурациям безопасности и вообще к любому объекту с жизненным циклом. Everything-as-Code здесь не лозунг, а архитектурное следствие: если ресурс существует в Kubernetes API, он автоматически версионируем, аудируем, управляем через GitOps.

Евдокимов объясняет, как устроены CRD (Custom Resource Definitions), как писать операторы, и почему правильно понятый KRM убирает необходимость в отдельных инструментах управления конфигурацией для многих сценариев.

Кому смотреть: platform engineering командам и SRE, которые уже используют Kubernetes и думают о расширении его за пределы стандартных ресурсов — управление инфраструктурой, политиками, секретами через единый API.

Из этого можно взять в работу: посмотри, какие операции ты делаешь через скрипты или сторонние инструменты, которые по сути управляют состоянием системы. Можно ли выразить это как Kubernetes-ресурс с оператором? Если да — ты получаешь GitOps, аудит и версионирование бесплатно.

Автор: Олег Казаков · Spectr

Олег Казаков — CTO в Spectr, выступал на митапе Spectr в сентябре 2025 года. Spectr — продуктовая IT-компания, и Казаков рассказывает о внедрении observability изнутри: не как консультант, а как человек, который жил с проблемой и решал её в работающем продукте.

«Тушение пожаров» — это диагноз: команда реагирует на инциденты после того, как они случились, вместо того чтобы видеть деградацию заранее. Observability меняет режим работы с реактивного на проактивный. Казаков разбирает, как это сделать без enterprise-бюджета: стек Prometheus + Loki, который покрывает 90% потребностей продуктовой команды, и подход к внедрению в существующий продукт без остановки разработки. Центральный тезис: не нужен Datadog за сотни тысяч долларов в год. Нужны правильные метрики, алерты, которые срабатывают до того как пользователи пишут в поддержку, и процесс, который команда реально использует.

Кому смотреть: CTO и техлидам продуктовых компаний, у которых observability — это «когда-нибудь потом» или «слишком дорого», и которые хотят конкретный стек и подход для старта.

Из этого можно взять в работу: определи три метрики, которые лучше всего описывают здоровье твоего продукта (p95 latency, error rate, длина очереди задач). Настрой алерты только на них — всё остальное потом. Три правильных алерта лучше, чем 300 шумящих.

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях, объясняет практики разработки коротко и без академической перегруженности. Этот выпуск — девятиминутный обзор Extreme Programming (XP).

Большинство разработчиков знают отдельные XP-практики: TDD, парное программирование, непрерывная интеграция. Многие применяют их в изоляции. Суть XP в том, что эти практики спроектированы как система: TDD даёт быструю обратную связь, парное программирование распределяет знание о коде, CI гарантирует, что интеграция не накапливает долг. Убери одно — другие становятся менее ценными. XP существовал до Agile Manifesto (Кент Бек опубликовал книгу в 1999-м), и многие принципы манифеста 2001 года прямо из него вышли. При этом XP как целостная система встречается в командах гораздо реже, чем Scrum, — хотя технические практики у него сильнее.

Кому смотреть: разработчикам, которые применяют TDD или CI по отдельности и хотят понять, зачем Кент Бек сложил всё это в одну методологию.

Из этого можно взять в работу: выбери две XP-практики, которые ты уже используешь (например, TDD и ревью кода), и попробуй применить их в связке — напиши тест вместе с коллегой до написания кода. Системный эффект виден только в паре.

Автор: Антон Солдатов · Podlodka Podcast

Антон Солдатов работал в IPONWEB — высоконагруженном ad-tech — и участвовал в разработке внутреннего форка LuaJIT. Это человек, который использовал Lua не в хобби-проектах, а в production-системах под серьёзной нагрузкой.

Lua занимает странное место в списке языков: его редко выбирают для нового проекта «с нуля», но он встроен буквально везде — в Nginx (OpenResty), Redis, Neovim, World of Warcraft, Roblox. Причина одна: Lua проектировался как язык для встраивания в хост-приложение, а не как самостоятельный рантайм. Он крошечный (библиотека меньше 300 KB), быстрый в встраивании, и позволяет дать пользователю возможность расширять систему без доступа к её исходникам. Антон объясняет, почему именно Lua, а не Python или JS, стал де-факто стандартом для этой задачи — и почему альтернативы проигрывают в этой конкретной нише.

Кому смотреть: разработчикам, которые строят платформы или приложения с пользовательской расширяемостью — плагины, скрипты, пользовательские правила обработки.

Из этого можно взять в работу: если ты строишь систему, которую пользователи должны кастомизировать, посмотри на Lua как на язык плагинов. Он добавляет расширяемость без того, чтобы отдавать пользователю весь рантайм.

Автор: Дмитрий Польшаков · DSR Corporation RU

Дмитрий Польшаков — Lead Software Engineer в DSR Corporation и преподаватель курса Embedded Systems Lab. Он объясняет профессию изнутри, без рекламной шелухи.

Embedded-разработчик пишет код, который живёт в микроконтроллере без операционной системы — или с RTOS, где каждый байт памяти и каждый такт процессора на счету. Главное отличие от прикладной разработки не в языке (C и C++ встречаются в обоих мирах), а в ментальной модели: здесь нельзя «добавить памяти» или «перезапустить сервер». Код должен работать предсказуемо в реальном времени, часто на железе за два доллара. Это меняет всё — как пишешь, как отлаживаешь, как думаешь об ошибках.

Кому смотреть: разработчикам из веба и бэкенда, которые задаются вопросом, что находится «ниже» операционной системы — и стоит ли туда спускаться.

Из этого можно взять в работу: спроси себя — ты понимаешь, что происходит между нажатием кнопки и изменением пикселя на экране? Embedded — это о том, чтобы владеть этим стеком снизу доверху.

Автор: Listen IT · YouTube

Listen IT — образовательный канал об IT-методологиях и процессах, объясняет сложные концепции коротко и структурированно. Это видео — обзор Agile: не реклама и не критика, а попытка разобраться, чем Agile является на самом деле.

Большинство команд, которые «работают по Agile», работают по Scrum или Kanban — и это не одно и то же. Agile — это набор ценностей и принципов, сформулированных в Манифесте 2001 года. Он не описывает церемоний, ролей и спринтов. Scrum — это уже конкретный фреймворк, одна из возможных реализаций. Путаница между ними ведёт к тому, что команды «внедряют Agile» через ретроспективы и стендапы, не меняя при этом отношения к изменениям и клиенту — и потом удивляются, почему не работает.

Кому смотреть: разработчикам и тимлидам, которые участвуют в agile-церемониях, но не понимают, зачем они существуют. А также тем, кто слышит «мы agile-команда» и хочет проверить это утверждение на прочность.

Из этого можно взять в работу: спроси на следующей ретроспективе: «Какую ценность из Agile Manifesto мы фактически соблюдаем, а не просто декларируем?» Ответ покажет реальный зазор между заявленной методологией и тем, как команда работает.

Автор: Александр Алексеев · Папочка Разработки

Александр Алексеев ведёт канал о .NET-разработке, где объясняет архитектурные концепции без академической перегруженности. Это видео — один из лучших русскоязычных входных точек в DDD: без Эванса на 500 страниц, но с сохранением сути.

Domain-Driven Design принято считать сложным — и чаще всего путают причину сложности. Дело не в паттернах: агрегаты, репозитории, value objects можно выучить за вечер. Настоящая сложность DDD в другом: он требует, чтобы разработчики говорили на одном языке с теми, кто понимает предметную область. Без этого единого языка — Ubiquitous Language в терминах Эванса — код отражает не бизнес-логику, а то, как разработчик её понял. В больших системах этот разрыв со временем становится главным источником багов и рефакторингов.

Александр разбирает, почему DDD особенно важен именно для сложных, долгоживущих систем и почему его не стоит тащить в простые CRUD-приложения — это отдельный тезис, который стоит услышать до того, как начинать внедрение.

Кому смотреть: backend-разработчикам, которые слышали про DDD, видели аббревиатуру в вакансиях, но не понимают, зачем это нужно и когда это оправдано.

Из этого можно взять в работу: возьми любую сущность в своём коде — например, Order. Спроси себя: это слово означает одно и то же для разработчика, менеджера и бухгалтера? Если нет — у вас нет Ubiquitous Language, и DDD пока не начинался.

Автор: Артём Шумейко · YouTube

Артём Шумейко — Python-разработчик и преподаватель, специализируется на backend. В коротком видео показывает на живом примере и с реальными цифрами, как FastAPI обрабатывает больше тысячи запросов в секунду.

Асинхронность часто объясняют через «это быстро» — и это неточная формулировка, которая потом мешает. FastAPI не делает CPU-код быстрее. Он устраняет простой: пока один запрос ждёт ответа от базы данных или внешнего сервиса, event loop берёт следующий. При I/O-bound нагрузке это даёт кратный прирост пропускной способности без дополнительных потоков и без накладных расходов на переключение контекста. Видео полезно тем, что показывает разницу измеримо, а не концептуально.

Кому смотреть: Python-разработчикам, которые пишут async/await по инерции или «потому что так принято в FastAPI», но не могут объяснить, почему это работает и когда это не поможет.

Из этого можно взять в работу: найди в своём коде async-функцию, которая делает блокирующий вызов — requests.get() вместо httpx, time.sleep() вместо asyncio.sleep(). Одна такая точка блокирует весь event loop.