Девушка - разработчик? Знает больше чем ты

Новое видео: YouTube | VK | Rutube

В новом ролике с приглашенной разработчицей Эвелиной, студенткой 3 курса информационной безопасности, провели интервью на junior backend.

На собеседовании разобрали вопросы работы с куки, хэшированием паролей, асинхронности, работы с микросервисами и индексами. А во второй части решили практические задачи на словари в Python, решили задачу на код-ревью и SQL-задачу.

Я сам давал объяснение, если собеседница не могла ответить, поэтому видео будет полезно всем, кто готовится к интервью и хочет понять, чего ожидать

Завел отдельный канал для тех, кто хочет прокачаться в параллелизме и конкурентности в Python

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

👉 Подписаться
👉 Подписаться

P.S. На аватарку поставил ии-чубзика, а то у питона нету норм маскота)

Иллюзия скорости в Python

Я знаю, что многие разработчики, когда только начинают писать асинхронный код, очень быстро впадают в зону комфорта — пишешь себе async/await, все работает — и кажется, что ты познал асинхронность. Кто-то даже параллелит запросы через gather)

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

Но стоит попасть в компанию с непростой бизнес-логикой, высокими нагрузками и реальными требованиями к лейтенси, может поехать кукуха от резкого наплыва новой инфы. Например, в проде будет 10-15 воркеров, кубернетес, тяжёлые операции, которые нужно выносить в потоки, процессы или очереди типа celery/taskiq, и всё это должно консистентно работать вместе. И вроде, чтобы нормально справляться с задачами, нужно уметь в параллельность и конкурентность в Python, но как только копаешь чуть глубже в эти темы — понимаешь, что не все так просто.

Приведу пример с прода. Например, хэширование паролей или тяжёлые валидации являются синхронными операциями, они блокируют событийный цикл на 50-200 мс так, что воркер перестаёт отвечать на запросы — и ты можешь просто не понимать, почему апишка начинает тупить уже при 10-20 запросов в секунду, хотя, казалось бы, всё написано асинхронно и локально работает нормально.

Или например, у знакомого был на проде цикл с while True + asyncio.gather и у них со временем сильно росла оперативка, и они не понимали почему — приходилось убивать контейнер и поднимать заново. А дело было в том, что разработчик не учел, что в gather при падении одной таски все остальные продолжают работать! В итоге накапливался снежный ком из задач, который постепенно сжирал память процесса.

И вот такие баги случаются обычно на проде, когда локально у тебя вроде все ок работает, а при реальной нагрузке начинает тормозить/падать.

Продолжение можно прочитать тут.

Мне очень нравится эта тема, хочу вам побольше рассказать о ней. Но сначала ответьте на вопрос в комментах 👇
- Что в теме параллельности/конкурентности/асинхронки в питоне для вас самое сложное?

Топ вопросов по Docker с собеседований с разбором ответов

Новое видео: YouTube | VK | Rutube

В новом видео я разобрал ключевые вопросы по Docker, которые регулярно задают на собеседованиях на backend-разработчика, а именно:

Что такое Docker и какие проблемы он решает
Чем отличается образ от контейнера
Как собирается образ
Чем отличается RUN от CMD
Что не нужно помещать в Docker-образ
В чем разница между Volumes и Bind Mounts
Что такое EXPOSE в Dockerfile
Как контейнеры общаются между собой
В чем разница между Docker и Docker-Compose
Зачем знать Docker, если в компании есть Kubernetes
Как работает кэширование при создании образа
Чем отличается CMD от ENTRYPOINT

В видео разобрал все, что нужно знать про Docker, чтобы успешно подготовиться к собеседованиям

Утечка памяти на фронтенде — да, такое бывает

Пару месяцев назад у нас в Солвите начал периодически умирать фронтенд. Просто в какой-то момент Docker-контейнер останавливался, и Nginx показывал 504 ошибку, т.к. некуда было вести пользователя.

Когда я полез разбираться, оказалось, что контейнер с фронтендом раздувался по памяти до 3–4 гигабайт, хотя должен был занимать около 1-1.5 гб. Из-за этого на сервере заканчивалась оперативка, и Docker-контейнер автоматически падал

Казалось бы, откуда на фронтенде утечка памяти? Он же вроде как "только в браузере" работает. Но у нас SSR (писал про него раньше), а это значит, что фронтенд запущен как отдельный Docker-контейнер, внутри которого крутится Node.js. В Солвите несколько тысяч задач с собеседований и вопросов для подготовки, и все эти страницы кэшируются для SEO-оптимизации* — и это довольно уязвимое место, где легко может возникнуть проблема с памятью. *SEO-оптимизация - это когда поисковики типа яндекса и гугла отображают твой сайт в поиске, для этого все страницы должны отдаваться сразу как готовый HTML код со всеми данными внутри.

Сначала фронтендер пытался найти утечку, потратил неделю, но так и не нашёл. Потом я сам несколько раз садился разбираться, тратил по паре часов — и тоже сдавался, потому что был рабочий костыль: просто перезапускаешь CI/CD пайплайн в гитлабе, память у контейнера сбрасывается, и ещё несколько дней он нормально себя чувствует, пока не начинает грузить оперативу. Перезапускали примерно два раза в неделю, и так мы жили около двух месяцев. (ну а чо, костыль рабочий)

В какой-то момент я даже докупил оперативки на сервер, и проблема вроде как отступила — утечка останавливалась где-то на 3,5–4 гигабайтах и дальше почти не росла. Но меня всё равно не покидало ощущение, что это какой-то бред и так быть не должно. И вот однажды меня это окончательно выбесило, и я решил сесть и разобраться до конца. Сделал специальные ручки для дебага на фронтенде, чтобы смотреть, сколько памяти занимают разные закэшированные страницы, и, конечно же, отправлял эти данные в ChatGPT, чтобы вместе разобраться, в чём проблема. Пару дней смотрел на них — и наконец понял, в чём дело.

Чтобы вы понимали контекст: перед тем как серверная сторона фронтенда сгенерирует HTML и отправит его в браузер, она должна получить из нашего внутреннего хранилища ссылку на OG-изображение для этой страницы, чтобы при шаринге ссылки картинка красиво отображалась. Так вот, проблема была в том, что в каждую страницу подгружалось не одно нужное изображение, а всё хранилище целиком — все три тысячи записей. То есть у нас было 3000 страниц, и в каждой лежало 3000 JSON-объектов с названием, путём и полной ссылкой на картинку — это 9 миллионов лишних записей, которых там быть не должно. Если прикинуть в байтах: один объект весит около 150 байт, а 9 миллионов × 150 байт ≈ 1.3–1.5 гигабайта лишних данных. Плюс, как оказалось, там ещё сохранялись другие данные, и суммарно всё это занимало лишние 2–2.5 гигабайта оперативки.

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

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

Кстати, ранее я писал про другой факап — с фичей "Итоги года". И сейчас я думаю, что эта история с OG-изображениями из той же серии: фича принесла много проблем, а большой продуктовой ценности не несёт. По сути это просто способ пофаниться, чтобы ссылки красиво выглядели при шаринге в соц. сетях. Стоило ли оно того — большой вопрос.

Расскажите в комментах, какие у вас были утечки памяти

🔥 — был опыт с утечками памяти
👍 — не сталкивался

Деплой — Разбираем популярные вопросы с собеседований

Новое видео: YouTube | VK | Rutube

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

— зачем нужен веб-сервер и какую роль он играет
— что такое zero downtime и как его достигают
— graceful shutdown и почему он важен при остановке сервиса
— основные стратегии деплоймента
— какие бывают стенды и как они используются
— как работают feature flags
— что такое хранилище образов
— как устроены процессы CI/CD

Видео поможет структурировать знания по деплою и подготовиться к собеседованиям, рекомендую к просмотру.

Последние 2 недели активно освежаю свои знания по параллелизму в Python — асинхронка, многопоточка и процессы, работа с сокетами и т.п.

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

Обычно это выглядит так: иду с утра в кафешку, беру с собой ноут, и кофе/какао на месте. Смотрю разные курсы и черпаю самое сочное из них, самое интересное конспектирую

Есть, кто в асинхронке/поточке плавает?) 👇

Как стать крепким Backend разработчиком за 3 месяца?

Если вы хотите построить карьеру разработчика, вам нужно выстроить эффективный план изучения необходимых навыков.

Такой план уже собран мной на курсе "BACKEND РАЗРАБОТКА НА PYTHON", который является выжимкой всего моего опыта в сфере разработки.

Формат: Онлайн-обучение на платформе с поддержкой наставников
Длительность: 3 месяца
Уровень: необходимо уметь писать функции и классы на Python, иметь минимальный опыт написания асинхронного кода (async и await) и SQL запросов (SELECT, UPDATE, INSERT)
Практика: 30+ заданий и тестов + 2 полноценных проекта в портфолио

На обучении вы освоите современный стек для Backend-разработки на Python. Рассмотренные мною библиотеки и технологии закрывают более 90% требований на рынке вакансий на уровень junior+ / middle.

Чему вы научитесь на курсе:
Быть в курсе спроса на рынке труда и понимать, почему выбирают Python для backend
Создавать мощные API с использованием FastAPI и Pydantic
Правильно хранить и извлекать данные с помощью SQL-запросов
Настраивать безопасность и авторизацию в приложениях
Производить интеграцию с платежными системами и внешними API
Автоматизировать процессы с помощью Celery и Redis.

Обучение включает:
1. Концентрированные короткие видеоуроки
2. Поддержку наставников-практиков и сообщество разработчиков
3. Решение задач, тестов и самостоятельную реализацию проектов

Переходите на сайт, чтобы и изучить программу и посмотреть отзывы.

Если у вас есть вопросы по обучению, записывайтесь на бесплатную экскурсию: расскажем и покажем, как проходит обучение

Записаться на экскурсию

Решаю задачи с собеседований Python Middle Backend

Новое видео: YouTube | VK | Rutube

В новом видео решаю 3 задания с собеседований на Python Middle Backend разработчика:
— непростую задачу на декораторы
— live coding задачу
— код-ревью

Смотрите видео и пишите, получилось ли решить задачи и смогли ли бы вы пройти такое собеседование на мидла 👇

Какой способ аутентификации выбрать: сессии или JWT?

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

— JWT используются там, где проще и безопаснее были бы сессии
— session-based подход в микросервисной архитектуре, где они неудобны
— непродуманное хранение, обновление и инвалидация токенов
— проблемы с безопасностью и масштабированием

Чтобы принимать верные решения, нужно понимать как устроена вся система аутентификации.

В новой статье мы последовательно разобрали тему:

различия между регистрацией, аутентификацией и авторизацией
как работает session-based подход и где хранятся сессии
JWT: структура, access/refresh токены
безопасность и хранение токенов
продление и инвалидация
сравнение подходов и выбор под задачу
работа с cookie и заголовками

Если хочешь понимать, когда и зачем использовать тот или иной подход, рекомендуем прочитать.

Читать статью

Пользователи просят эту фичу, а мы отказываемся ее делать

Продолжаю серию постов про развитие Солвита, и сегодня хочу поговорить про фичу, которую нам регулярно просят, а я каждый раз отказываюсь от мысли её реализовать — раздел с комментариями, что-то типа форума, где можно пообщаться, оставить реакцию на задачу, написать своё решение и поспорить с чужим.

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

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

При этом мы всё равно хотим получать обратную связь от пользователей. Скоро зарелизим новую фичу с разобором решения лайв-кодинг задач, и сделаем систему оценки решения через лайки/дизлайки, причём после нажатия дизлайка можно будет прикрепить комментарий с отзывом, что именно не понравилось. Но увидим его только мы — это довольно безопасный способ собирать фидбек без ущерба для других посетителей сайта и без необходимости что-то модерировать.

Понятно, что если активность на сайте огромная и комментариев пишут очень много, то всякий шлак сам будет опускаться вниз, потому что его никто не лайкает, и система ранжирования автоматически поднимает наверх самое полезное. Но до этого нужно дорасти, а у нас сейчас огромное количество задач и вопросов (более 3000), и я сомневаюсь, что мы можем добиться достаточной активности в каждом из них, чтобы эта система самомодерации реально заработала.

А вам вообще важны комментарии на образовательных платформах?

— комментарии нужны, это же комьюнити
👍 — и без них норм, главное контент

Решаю SQL задачи с собеседований в Ozon и WB

Новое видео: YouTube | VK | Rutube

В новом видео решаю SQL задачи в крупнейшие маркетплейсы. Подготовил 3 задачи, одна из которых нетипичная для SQL. В видео объясняю свои решения и показываю альтернативные, поэтому будет полезно всем, кто как-либо связан с языком SQL.

Думаешь о работе в бигтехе? Держи нагрузку 5 RPS

Когда я только начинал путь в разработке, у меня была такая романтичная картинка: вот ты приходишь в условный Яндекс/Авито, пишешь код, который должен выдерживать миллионные RPS, и он используется миллионами людей. Например, пишешь поиск, или карты, или главную страницу — и это прям продукт, которым пользуются тысячи и миллионы людей.

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

Почти все команды в Бигтехе (VK, Т-Банк, Сбер, Альфа, Яндекс), куда я собеседовался, делали что-то внутреннее. Не ядро продукта, а сервисы вокруг него: инструменты для других отделов, платформы для аналитиков, автоматизация процессов, ETL скрипты. И это не какая-то работа для джунов на подхвате — это действительно огромный пласт задач, без которого публичный продукт просто не выживет. И часто в таких проектах важнее не то, что он выдержит 10000 запросов в секунду, а будет корректно работать, и легко развиваться, т.е. больший упор делается на понятность кода и масштабируемую архитектуру.

Когда я работал в Самокате, я не писал приложение для курьеров или каталог товаров (как вы могли подумать). Я разрабатывал аналитическую платформу, настраивал Airflow, занимался перекачкой и трансформацией данных (то бишь ETL). Звучит не так эффектно как "я разрабатывал сервис под 100к RPS", но без этой инфраструктуры бизнес вообще не понимает, что происходит с продуктом, и развитие идет медленнее.

И таких внутренних сервисов в любой крупной компании — десятки:
— корпоративные соцсети и порталы для сотрудников
— внутренние CRM для продажников
— платформы для A/B тестирования
— системы нотификаций и алертов между сервисами
— общие переиспользуемые библиотеки и решения для всех команд разработки

У нас в Солвите, кстати, похожая история. Есть основной продукт — платформа для подготовки к собесам. Но вокруг него живёт куча внутреннего кода, который пользователи никогда не увидят: система проверки решений в лайв-кодинге, сервис коммуникации с менторами и сбора отзывов, отправка уведомлений в телеграм-чаты с важными событиями (фидбек, проблемы с оплатой, срочные вопросы). Всё это — тоже бэкенд, просто его "пользователи" — мы сами и наши процессы.

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

🔥 — пилю продукт, который видят юзеры
👍 — делаю внутренние инструменты (например, для сотрудников)
— и то, и другое

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

На этом этапе важно не усложнять себе жизнь и сразу выбрать нормальный сервис, который будет закрывать все потребности вашего проекта.

Вот 5 причин, почему для этого часто выбирают Selectel:

1. Низкие цены на регистрацию имен в зонах .RU/.РФ. — всего 120 рублей. Прозрачный биллинг без дополнительных комиссий.

2. Бесплатные SSL-сертификаты и DNS-хостинг.

3. Если уже есть свой домен, перенос и продление будет всего по 1 рублю до конца июня.

4. Не только домены: можно развернуть полноценную ИТ-инфраструктуру на базе облака, выделенных серверов и 50+ других сервисов. Все доступно в одном окне браузера.

5. Надежность провайдера с 17-летним опытом на рынке, 31+ тысячами клиентов и шестью собственными дата-центрами. Стабильная работа и бесплатная техподдержка обеспечены.

📍 Регистрируйте, переносите и продлевайте домены в Selectel: https://slc.tl/spgc8
Реклама. АО «Селектел» ИНН 7810962785 Erid: 2W5zFK5dJLq

Как мы защищались от реальной DDoS-атаки

Несколько месяцев назад я выпустил пост про защиту от DoS-атак, где разбирал теорию и базовые подходы. И видимо, кто-то из читателей решил по фану устроить мне реальную проверку, потому что буквально после этого начались регулярные DDoS-атаки — примерно каждые 2-3 дня.

Если кто подзабыл разницу: DoS — это когда условно один компьютер пытается завалить твой сервис запросами, а DDoS — когда это делает целая толпа машин с разных IP-адресов, и блокировать их по одному становится тяжело. Кстати, атаки шли не с российских IP-адресов, а с иностранных, что добавляло ситуации какой-то особой пикантности.

Меня, честно говоря, очень повеселил тайминг этих атак — они приходили в первом часу ночи. В это время сайтом вообще почти никто не пользуется, на графиках в Grafana в эти часы обычно ноль активности. На скриншоте прикрепил одну из атак в 01:40 ночи :) Я до сих пор не понимаю, почему именно ночью — то ли у хакеров такой рабочий график, то ли они специально выбирали время, когда пользователей меньше. Если второе, то даже как-то благодарен им за такую заботу, что не стали ддосить днём, когда на платформе занимаются реальные пользователи.

В моменте было около 15 тысяч активных TCP-соединений — это в сотни раз больше обычной нагрузки, которую Nginx видит в нормальной жизни. Причём атака шла именно на фронтенд, а не на бэкенд-ручки.

Нам нужно было решение, которое будет автоматически блокировать подозрительные IP-адреса без ручного вмешательства, поэтому мы поставили fail2ban — это такой софт, который банит IP на уровне iptables. Если что, iptables — это встроенный в Linux инструмент для управления сетевым трафиком, по сути фаервол на уровне ядра ОС, который позволяет фильтровать пакеты по разным правилам. Вручную банить айпишники хакеров в iptables каждый раз — удовольствие сомнительное, а fail2ban работает как умная прослойка: он смотрит логи Nginx, и если какой-то IP-адрес за условные 10 минут получает несколько 503 или 429 ошибок, то сразу выписывается бан на сутки. Причём блокировка происходит на уровне ОС, т.е. запрос даже не доходит до nginx или веб-сервера, IP отсекается заранее.

Ещё в процессе мы признали косяк с кэшированием — в момент атак выяснилось, что у нас не было нормально настроено кэширование статики на уровне Nginx во фронтенде, и это было реально сильное упущение, которое мы потом пофиксили. Учитывая, что атака била именно по фронту, отсутствие кэша било особенно больно.

За последние несколько месяцев fail2ban отлично справляется — у нас не было ни одного всплеска активности и проблем с доступностью. Возможно, атаки и продолжаются, но я об этом просто не знаю, потому что до веб-сервера они уже не долетают

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

Кто как справляется с нежелательным трафиком?

В телегу завезли новую фичу с изменением текста через ИИ

Так что если в очередной раз рекрутер прислал вам отказ, можно переписать свое сообщение так:

3 года пишу на Python — все еще джун? Собеседование Python Junior разработчика

Новое видео: YouTube | VK | Rutube

В новом ролике с приглашенным разработчиком Владиславом, который 3 года пишет на Python, провели интервью на junior backend.

На собеседовании разобрали вопросы работы с фреймворками, аутентификации и авторизации, асинхронности, работы с базами данных и микросервисами. А во второй части решили практические задачи на типы данных, написание асинхронной функции, решили задачу на код-ревью и SQL-задачу.

Я сам давал объяснение, если собеседник не мог ответить, поэтому видео будет полезно всем, кто готовится к интервью и хочет понять, чего ожидать

Unit of Work — паттерн, который вы (скорее всего) неправильно понимаете

Пару лет назад я наткнулся на одну интересную статью, где довольно подробно разбирался паттерн Unit of Work на примере Flask. Тема показалась мне крутой, и я решил раскрыть её для FastAPI — записал отдельное видео, которое набрало достаточно много просмотров,... а потом мне пришлось его скрыть.

Потому что я понял, что сам же и накосячил с трактовкой паттерна. И что любопытно — до сих пор вижу в проектах, статьях и туториалах ровно ту же ошибку, которую допустил я. Давайте разберёмся, в чём подвох.

Что обычно называют Unit of Work
Чаще всего я вижу примерно такой код, который называют "паттерном UoW":

class UnitOfWork:

    def __init__(self):

        self.session = async_session_maker()



    async def __aenter__(self):

        self.users = UserRepository(self.session)

        self.orders = OrderRepository(self.session)

        return self



    async def __aexit__(self, exc_type, *args):

        if exc_type:

            await self.rollback()

        await self.session.close()



    async def commit(self):

        await self.session.commit()



    async def rollback(self):

        await self.session.rollback()

И используется это примерно так:

async def create_order(user_id: int, items: list):

    async with UnitOfWork() as uow:

        user = await uow.users.get(user_id)

        order = await uow.orders.create(user, items)

        await uow.commit()

        return order

Код отлично подходит для создания транзакционности, я сам такое использую. Но называть это Unit of Work — некорректно.

Что такое настоящий Unit of Work
Изначальная трактовка паттерна про другое: UoW накапливает все изменения объектов в памяти, а когда вы закончили — сам разбирается, какие INSERT, UPDATE и DELETE нужно выполнить. То есть это он отвечает именно за отслеживание состояния объектов, а не является обычной обёрткой над транзакцией.

В SQLAlchemy есть встроенная реализация паттерна Unit of Work — Session отслеживает все объекты и при commit() генерирует нужные запросы:

session.add(user)  

# session запомнила: "надо вставить user"

user.name = "Артём"  

# session запомнила: "надо обновить user"

session.delete(order) 

# session запомнила: "надо удалить order"

session.commit()  

# session сгенерировала INSERT, UPDATE, DELETE

То, что описано в комментариях в коде, алхимия делает под капотом именно через паттерн unit of work. (код самого uow я не показываю, если что — можете найти примеры или первоисточники)

Но на практике я не так часто встречал, чтобы именно этот механизм использовался. Гораздо чаще вижу работу через классический session.execute(), когда мы просто экзекьютим какой-то запрос, а не используем ORM-магию алхимии с отслеживанием объектов (всякие add, delete, flush, refresh).

Как тогда называть наш класс?
Я предпочитаю называть такой класс как DBManager или TransactionManager, т.к. это честнее отражает суть — это удобная прослойка для управления транзакциями и доступа к репозиториям, не более.

Правда преимущества такого подхода никуда не деваются от правильного названия:
— можно шарить одну транзакцию между разными репозиториями и сервисами приложения
— удобный доступ к репозиториям без миллиона импортов (просто uow.users.get() вместо импорта класса/экземпляра репозитория каждый раз from some.other.folder.repo.user import UserRepository или дичи по типу помещения нужных репозиториев внутрь __init__ сервиса)
— явный контроль над тем, когда делать commit

Вывод
Если честно, не так важно, как этот класс называется в вашем коде — главное, что вы понимаете, зачем он нужен и какие преимущества даёт. Но понимать разницу между настоящим паттерном UoW и обёрткой над транзакцией всё-таки стоит, чтобы на собесе не попасть в неловкую ситуацию. Хотя, справедливости ради, про Unit of Work спрашивают примерно раз в тысячу лет.

А у вас как называется этот класс в проектах? И вообще, используете такую прослойку или работаете с сессиями напрямую?

— использую похожую обертку
👍 — работаю с сессиями напрямую

Завел себе микрочелика, теперь будем жить вместе)

Мы ей имя уже дали, но предложите варианты в комментах, как можно смешно кошку назвать)) Типа "багуля" или что-то на программистском