Системный анализ | Ольга Пономарева

Самые частые ошибки в архитектурных решениях 🌚

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

Делимся тремя горячими:

1️⃣ Дублирование кодов ответа в теле
В ответе на запрос пишут ""code"": 200 и при этом в заголовках HTTP уже летит 200 OK. Зачем дублировать? Это лишний трафик, путаница, консистентность. Код ответа является метаданными, она живёт в заголовках HTTP. В теле достаточно возвращать только бизнес-данные и, если нужно, свой кастомный код для внутренней логики. А HTTP-статус уже говорит сам за себя.

2️⃣ Одна общая база данных на несколько сервисов
!!! Технически это не запрещено. В реальных проектах такое встречается. Но как только два сервиса начинают писать в одну базу, ты теряешь независимость. Изменение схемы одной таблицы тянет изменения во всех сервисах-соседях. И ещё вопрос: кто отвечает за миграции? Кто гарантирует целостность, если один сервис упадёт посреди транзакции? Такое решение требует жёстких договорённостей и сильной дисциплины в команде.

3️⃣ Брокер вместо синхронного запроса
Вместо того чтобы дёрнуть API и получить мгновенный ответ, ставят брокер сообщений. И получают усложнение инфраструктуры, задержки и головную боль с подтверждениями. Если тебе не нужна асинхронность, если клиент ждёт результат здесь и сейчас, брокер не нужен. Используйте синхронные вызовы там, где они уместны."


❗️Хочется отметить: само по себе решение редко бывает "плохим" или "хорошим". Вопрос в том, зачем вы его выбрали и какие последствия этого выбора понимаете. Именно это мы и разбираем на домашних работах!

В задаче обычно остаётся, что нужно сделать. В документации — как это должно работать. А всё обсуждение о том, почему команда выбрала именно такое решение, часто продолжает жить только в проектном чате

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

В карточках собрали, что точно стоит вытаскивать из переписки и фиксировать отдельно 👆

А теперь представьте, что всю историю проектного чата можно автоматически разобрать: найти темы, вопросы, решения и противоречия, а затем связать их с исходными сообщениями 👀

У вас важные решения переносят из чатов в документацию или всё остаётся в переписке?

Реальный кейс, с которым работает один из экспертов нашей школы

Есть система1, которая для своей внутренней логики нуждается в данных из системы2.

Немного НФТ:
- объём данных -- 100 ГБ
- 30 млн записей, в каждой по 30 полей
- все данные лежат в одной таблице

Вопрос: как организовать передачу?

Какие варианты видите? Что предложите?


p.s. REST вообще не вариант. Если отправишь запрос с телом в 100 ГБ, твой REST API умрет мучительной смертью на первом же сетевом устройстве. Серверы не читают файлы "на лету" частями. Большинство REST-фреймворков пытаются загрузить весь payload в оперативную память (RAM), чтобы распарсить его в объект. 100 ГБ в RAM это фантастика. У тебя просто нет столько памяти. Сервер упадет с ошибкой Out Of Memory (OOM) раньше, чем ты получишь первый байт данных в контроллере

Самые частые ошибки в архитектурных решениях

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

Делимся тремя горячими:

1. Дублирование кодов ответа в теле
В ответе на запрос пишут ""code"": 200 и при этом в заголовках HTTP уже летит 200 OK. Зачем дублировать? Это лишний трафик, путаница, консистентность. Код ответа является метаданными, она живёт в заголовках HTTP. В теле достаточно возвращать только бизнес-данные и, если нужно, свой кастомный код для внутренней логики. А HTTP-статус уже говорит сам за себя.

2. Одна общая база данных на несколько сервисов
!!! Технически это не запрещено. В реальных проектах такое встречается. Но как только два сервиса начинают писать в одну базу, ты теряешь независимость. Изменение схемы одной таблицы тянет изменения во всех сервисах-соседях. И ещё вопрос: кто отвечает за миграции? Кто гарантирует целостность, если один сервис упадёт посреди транзакции? Такое решение требует жёстких договорённостей и сильной дисциплины в команде.

3. Брокер вместо синхронного запроса
Вместо того чтобы дёрнуть API и получить мгновенный ответ, ставят брокер сообщений. И получают усложнение инфраструктуры, задержки и головную боль с подтверждениями. Если тебе не нужна асинхронность, если клиент ждёт результат здесь и сейчас, брокер не нужен. Используйте синхронные вызовы там, где они уместны."

Какой коллега — твой главный кошмар?

Мы, аналитики, общаемся со всеми: заказчики, разработчики, архитекторы, тестировщики и все, кто только есть в команде. Но со всеми ли легко находить общий язык?)

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

А у вас есть коллеги, от которых глаз начинает дергаться?

И отдельный вопрос: где вы фиксируете финальное решение, если в процессе разработки всё поменялось?

Сейчас снова проблемы с топливом — и приложение «ГдеБЕНЗ» опять как нельзя кстати

Помните его историю?

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

И мы тут подумали…:

Наверняка среди вас тоже есть те, кто уже завайбкодил своё приложение, сайт или сервис, но ему не хватает пользователей и нормальной обратной связи

Поэтому присылайте свои проекты нам в тг @care_sa

➡️ Самые интересные бесплатно покажем в нашем канале на 30 000+ человек — дадим аудитории потестировать, оставить фидбэк и, возможно, немного бустануть ваш проект 🚀

Что прислать: пару слов о проекте + ссылку/скрины

Почему нам это интересно?
Мы сейчас активно развиваем тему вайбкодинга и хотим чаще показывать не теорию, а реальные проекты и людей, которые их делают.
Поэтому вам — аудитория и обратная связь, нам — классные реальные кейсы для канала 💛

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

После прошлой версии курса по архитектуре мы получили замечания, что он оказался слишком лёгким. Собственно, поэтому мы его и переделали: разделили программу на Базу и Хард, усилили наполнение и практику

А в этот поток решили провести эксперимент — пригласили на обновлённые курсы тех, кто оставил самую развёрнутую и критичную ОС о прошлой версии

На первом скрине — отзыв одного из таких учеников. Кажется, эксперимент удался 🥹

А второй скрин — небольшое предупреждение для тех, кто сейчас проходит Хард 😎

Хард на то и Хард! После прошлой версии вы просили нас усложнить курс — мы усложнили. Поэтому домашки теперь действительно непростые и иногда могут занять не один вечер

Но зато представьте, с каким уровнем знаний и практики вы выйдете после курса 🤌

Vibe coding — программирование по атмосфере или настроению

А вы уже пытались "вайбкодить"? Какие результаты?

День 10. Финал марафона 💛

Вот и подошли к концу наши десять дней вместе

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

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

А теперь — финальный розыгрыш 🎁

Мы соберём комментарии под заданиями всех прошедших дней марафона и с помощью рандомайзера выберем трёх победителей.

Каждый победитель сможет получить на выбор:

— футболку школы;
— настольную игру;
— сборник ответов или задач для подготовки к собеседованиям.

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

Результаты объявим 13 августа 💛

И напоминаем: сегодня заканчивается не только марафон, но и распродажа. До 23:59 обучение можно приобрести со скидкой до 50%. После полуночи цены вернутся к обычным

💯 - если понравилось и проводить такое еще раз
❤️ - если хочется что-то другое (напишите в комментах что улучшить!)
👌 - если не понравилось и такое делать не нужно

День 9. Расскажите свою историю 💛

Сегодня задание будет особенно тёплым!

Расскажите в комментариях любую историю, которая связывает вас с нашей школой или Ольгой Пономаревой:

— как вы впервые о нас узнали;
— чем вам помогли наш курс, вебинар, Ольга или Telegram-канал;
— что изменилось в вашей работе после обучения;
— какой момент вам особенно запомнился;
— или просто поделитесь тем, как давно вы с нами и почему остались.

Здесь нет правильного формата или необходимого объёма. Главное — чтобы это была ваша настоящая история.

Среди всех участников мы с помощью рандомайзера выберем одного победителя. Он получит менторство со мной 🎁

Пишите свои истории в комментариях. Очень хочется сегодня узнать вас поближе 💛

Пока вы еще думаете "а нужно ли мне это" - другие учатся и наслаждаются процессом!

Архитектура. Хард в следующий раз стартует 28 сентября. Количество мест будет ограничено, и уже 13 человек успели забронировать место в рамках распродажи

В этом посте отвечали на популярные вопросы по курсам архитектуры

➡️ Выбрать курсы по выгодной цене можно до 12 августа