Павел Сорокин | Java

Почему сеть ненадежная и когда она упадет какие у нас есть варианты? Потому что всё, что проходит по сети - может потеряться. Сеть ненадежная штука, она отваливается: происходят сбои, задержки, пакеты могут не доходить или идти долго Вот типичная картина: клиент отправил запрос. На сервер. По HTTP. Казалось бы, обычная штука 1️⃣ Сценарий первый - запрос вообще не дошёл. Клиент повис, подождал, устал и отвалился 2️⃣ Сценарий второй - запрос дошёл, сервер его даже обработал, но ответ не вернулся. Потому что где-то между твоим сервером и клиентом случилось маленькое сетевое "пошёл ты нахуй" обрыв сети 3️⃣ Сценарий третий - запрос обработан, ответ отправлен, но клиент уже ушёл, потому что превышен timeout ожидания Что делает клиент? Он отправляет запрос снова. И это логично. Если у нас действительно надежная система, то нам нельзя терять сообщения и нужно их переотправить. Вдруг ничего не произошло и сервер не обработал? А вот тут начинается боль 😐 Собственно, здесь и появляется идемпотентность. Клиент присылает вместе с запросом уникальный requestId, а сервер запоминает, что такой запрос уже обрабатывался. Если он прилетает повторно, мы не списываем деньги ещё раз, а возвращаем результат первой попытки ❗️ Но и просто навесить retry на каждый вызов недостаточно, здесь уже рассказывал почему, если сеть моргнула на секунду - повтор поможет. Если соседний сервис лежит уже десять минут, тысяча клиентов с тремя ретраями превратит тысячу запросов в четыре тысячи и поможет сервису умереть чуть увереннее 💀 Поэтому нормальная работа с сетью - это не один волшебный паттерн, а несколько уровней защиты: 📌 timeout, чтобы не ждать ответ бесконечно 📌 ограниченный retry с backoff и jitter 📌 идемпотентность, чтобы повтор не создавал второй эффект (писал тут) 📌 Circuit Breaker, чтобы перестать ходить в сервис, которому уже плохо 📌 логи, метрики и tracing, чтобы узнать о проблеме раньше звонка клиента в пятницу вечером А если связь пропала между целыми частями системы, можно временно перестать принимать операции и сохранить строгую консистентность или же продолжить работать, разрешить данным ненадолго разъехаться и синхронизировать их позже Это и есть та часть CAP-теоремы, которую важно понимать на практике: когда между узлами случился network partition, нельзя одновременно гарантировать и всегда актуальные данные, и успешный ответ на каждый запрос. Чем-то придётся пожертвовать - всегда 🔫 Так что паттерны из прошлых постов придумали не ради красивых схем и вопросов на собеседовании. Они появились из одной довольно неприятной особенности распределённых систем: они распределенные Мораль такова

Сеть - это не ласковый и приветливый мир, здесь убивают 🔫 падают запросы

Дизайн, в котором пакеты всегда доходят, красив только в теории, в реальности такого не случается. При работе с сетью надо быть предельно аккуратным и продумывать проблемы, которые могут возникнуть. Ваша система должна уметь решать эти проблемы, чтобы быть надежной #хардовая_польза П.с. Первую и вторую части про паттерны микросервисов оставлю для чтения здесь и здесь 👀

Делай то, что важно, что неважно - не делай Недавно на стриме спросили хороший вопрос, хочу немного раскрыть тему Мы все хотим успевать больше: работать, делать свои проекты, учиться, заниматься здоровьем, проводить время с близкими, да и ещё куча всего интересного, что тоже хотелось бы попробовать Кажется, надо нормально организовать свой тайм-менеджмент, и тогда всё точно получится вместить в жизнь. Но ты живой человек, у тебя ограничены время, силы, внимание. Можно хотеть преуспеть хоть в десяти направлениях одновременно, только ресурсов у тебя не хватит Количество вещей, которые ты можешь сделать хорошо очень маленькое - нужно грамотно выбирать куда ты тратишь время В какой-то момент придётся выбирать и понять, что для тебя вообще важно в жизни?

Хочешь через пять лет быть там же, где сейчас, и делать то же самое или тебе важно что-то поменять?

И это, блин, действительно сложно сделать, есть огромное количество вещей, которые нравятся и прикольно было бы их сделать. Но даже от интересного придётся отказываться, если на то, что для тебя важнее, уже не остаётся ресурсов Постоянно отсекать неважное: не читать телегу просто по привычке, закрыть рилсы, не браться за ещё одну вроде классную затею И в тоже время нужно случайно не отсечь лишнего: отношения с партнёром, друзья, здоровье. Нельзя вычеркнуть их просто потому, что они не помогают тебе больше заработать или закончить проект Поэтому сначала пойми, что тебе дорого: что хочешь сохранить, что изменить, в каких нескольких вещах преуспеть. И уже под это выделять свои ограниченные ресурсы А потом каждый день продолжать делать этот выбор - один раз определить приоритеты недостаточно. Каждый день снова появляется что-то интересное, срочное, приятное, и нужно постоянно этому противостоять. Противостоять желанию начать что-то новое пока ты еще не закончил старый проект, почитать это, посмотреть то-то... Жертвовать чем-то всё равно придётся, и лучше жертвовать в пользу действительно важных вещей, отсекать "приятное и полезное", но неважное лично для тебя Успеть всё не получится, а выбрать, на что потратить свою жизнь, хочешь ты или нет, придётся

Заканчивается большая глава Sorokin School... Уже через 2 дня я закрываю продажи и после этого попасть на последний поток Java Backend уже не получится С этой программой мы прошли очень большой путь, и дальше хочу больше заниматься глубокими отдельными темами - архитектурой, систем-дизайном и другими инженерными штуками, в которые самому интересно закапываться А этот поток хочу провести так, чтобы самому было чем гордиться 😎 Поэтому в нём помимо основной программы с большим проектом EventManager будет 4 новых блока с моими практическими воркшопами: 🟣 AI и кодинг-агенты - постановка задач, контекст, MCP, скиллы и проверка изменений. Чтобы понимать, что агент натворил в проекте и можно ли это вообще оставлять 🟣 Микросервисы и Kafka - границы сервисов, события, повторы и сбои, что делать, когда на красивой схеме всё работало, а в реальности соседний сервис лёг 🟣 System Design - требования, нагрузка, выбор хранилищ и способы взаимодействия. Будем разбираться, почему система устроена именно так и какие у решения ограничения 🟣 CI/CD и Kubernetes - как код проходит сборку, тесты и попадает в работающее окружение. Потому что на «у меня локально запустилось» разработка обычно не заканчивается 🙃 На обоих тарифах - доступ к материалам Java Backend на год, общий чат и групповые воркшопы, а с ментором дополнительно - 5 месяцев поддержки, ревью домашних работ и 5 личных встреч: диагностика, 2 защиты проекта, технический mock и System Design собеседование И напоследок, поделюсь тем, о чем не говорил публично. Я собрал прям жирный-жир, если залетаешь до старта потока, то есть до 9 ноября, получаешь ещё 3 курса в подарок 🔥 🎁 Livecoding - алгоритмы, backend code review и SQL. Как решить задачу на собесе, проверить свой код и объяснить ход мысли, пока на тебя смотрит интервьюер))) 🎁 Многопоточность - потоки, память JVM, блокировки, пулы, CompletableFuture и virtual threads. С практикой, чтобы разобраться в причинах гонок и зависаний 🎁 Курс по трудоустройству - резюме, самопрезентация, технические и HR-собеседования, архитектура и испытательный срок: как готовиться и двигаться от учебного проекта к поиску работы В итоге на Java Backend ты собираешь и разбираешь собственный backend, а дополнительные курсы помогают глубже пройти многопоточность, потренировать собеседования и подготовиться к выходу на рынок Напиши Артёму, менеджеру школы - он поможет оформить участие и расскажет про доступные способы оплаты ⬅️ *Бонусы выдаются после полной оплаты обучения

Делай то, что важно. Что не важно - не делай

© Стэтхем Павел Сорокин Вы часто спрашиваете, как я распределяю время между работой, своими проектами и жизнью вне проги. И у меня на это самый банальный и простой ответ: сначала выделяю время на то, что для меня важно Звучит как совет уровня «чтобы выспаться, ложись пораньше» 😕 Но попробуй ещё пойми, что тебе важно, когда тебе и то хочется, и это, и вот это Есть огромное количество прикольных вещей, которыми хотелось бы заниматься. Только по определению всё в твою жизнь не влезет, придётся выбирать И в такие моменты, я думаю, что для меня важнее в долгосроке? Я хочу через пять лет заниматься тем же самым и жить так же? Или мне важно что-то поменять? Если поменять, то на это надо выделять время уже сейчас 🤷‍♂️🤷‍♂️🤷‍♂️ Например, друзья зовут вечером побухать, а я собирался в зал. Мне и с ребятами посидеть хочется, и потренить. Но если для меня важно долгосрочно быть здоровее и в хорошей форме, то нельзя каждый раз выбирать бар, а зал оставлять на «когда-нибудь потом»))) При этом отношения с друзьями тоже важны. Нельзя случайно вычеркнуть их вместе со всем остальным, а через пять лет обнаружить, что ты накачанный, продуктивный, успешный и поговорить тебе не с кем 😵 Вот это и сложно: разобраться со своими приоритетами и постоянно отсекать то, что в них не входит Отписаться от каналов, которые читаешь просто по привычке, закрыть рилсы, отказаться от ещё одной затеи, которая вроде прикольная, но сейчас тебе вообще не нужна Безжалостно убирать неважное, при этом не снести заодно то, что тебе действительно дорого У тебя 24 часа в сутках. Если выбрать одну, две, три вещи, в которых хочешь преуспеть, и перестать распыляться на всё остальное, времени на них станет сильно больше Жертвовать чем-то всё равно приходится. Если каждый вечер уходит на случайную херню, ты уже жертвуешь - временем, которое мог потратить на то, что действительно важно Не хочется негативить, но жизнь реально короткая, и тратить ее постоянно на то, что для тебя не важно, и тем более не нравится - плохая идея 🤢

Что будет с кодом, если данных станет в миллион раз больше? 🤔 Если хочешь нормально проходить live coding собеседования и понимать алгоритмы, нотация большого O - одна из первых вещей, с которой нужно разобраться. Написать работающее решение - это хорошо. Но дальше-то надо объяснить, насколько оно эффективно и что произойдёт, если данных станет в тысячу раз больше Для этого и нужна Big O. Она позволяет оценить, как растут затраты алгоритма вместе с размером входных данных. Обычно оценивают время работы или дополнительную память. Давай сначала подушню строгим определением, а потом разберем на примерах ⤵️

f(n) = O(g(n)), если существуют константы C > 0 и n₀, такие, что для всех n ≥ n₀ выполняется:
0 ≤ f(n) ≤ C · g(n)

Здесь n - размер входа, а f(n) может быть числом операций. Начиная с некоторого n₀, оно не превышает C · g(n). На простых функциях это выглядит так: • n² + 10n → O(n²) • 100n → O(n) • 3n log n + 10n → O(n log n) • n³ + n² → O(n³) • фиксированные 100 операций → O(1) Смотрим на самый быстро растущий член, постоянные множители отбрасываем. Например, для n² + 10n при n ≥ 10 выполняется n² + 10n ≤ 2n²: в определении подходят C = 2 и n₀ = 10. При этом Big O - верхняя граница роста: 100n подходит и под O(n²), но O(n) точнее. Обычно и ищут наиболее точную оценку. 10 линейных циклов подряд - всё ещё O(n). Прошли массив, потом ещё раз, и так 10 раз: n + … + n = 10n. Число проходов фиксировано, оно не растёт вместе с массивом А если внутри каждого из n шагов внешнего цикла выполнить ещё n шагов внутреннего, получим n · n = n², то есть O(n²). Работу на одном шаге здесь считаем O(1). Важны число итераций, а не просто количество for в коде. Так, что там по примерам ⤵️ ✏️  O(1) - константная сложность Например, получение элемента ArrayList по индексу: users.get(42); Хоть 100 элементов в списке, хоть миллион — перебирать предыдущие не нужно. O(1) не означает одну операцию: их количество не растёт вместе с n. Поиск по ключу в HashMap тоже ожидаемо O(1) - при хорошем распределении хешей и постоянной стоимости hashCode и equals. ✏️  O(n) - линейная сложность Поиск максимума в неотсортированном массиве: нужно посмотреть на все элементы. Данных в 10 раз больше - работы примерно в 10 раз больше. У LinkedList доступ к произвольному элементу по индексу - O(n) в худшем случае: до него нужно дойти от начала или конца. Поиск значения через ArrayList.contains - тоже O(n) в худшем случае. ✏️  O(log n) - логарифмическая сложность Самый простой пример - бинарный поиск. На каждом шаге отбрасываем примерно половину оставшихся вариантов. Например, для миллиарда элементов хватит около 30 шагов, если массив уже отсортирован (есть гайд на ютубе от меня) Логарифм встречается и в деревьях поиска. Например, TreeMap и TreeSet в Java используют красно-чёрное дерево: поиск, добавление и удаление занимают O(log n) в худшем случае Балансировка при вставках/удалениях удерживает высоту дерева в пределах O(log n): проходим путь по дереву, а не все элементы. У B-tree-индекса в БД та же идея: путь от корня до нужного листа имеет O(log n) уровней. Чтение всех подходящих строк добавляет работу, поэтому это ещё не оценка всего SQL-запроса. ✏️  O(n log n) - линейно-логарифмическая сложность С такой сложностью работают эффективные сортировки на сравнениях. Например, сортировка слиянием и пирамидальная сортировка гарантируют O(n log n) независимо от того, как расположены числа в массиве Для любой сортировки только на сравнениях доказана нижняя граница: O(n log n). Сортировки подсчётом и поразрядные могут быть быстрее при подходящих условиях: они используют свойства ключей. ✏️  O(n²) - квадратичная сложность Допустим, нужно посчитать количество пар в массиве чисел, сумма которых равна 10 (кстати тут в видео разбираю эту задачу полностью) В массиве [2, 8, 3, 7] таких пар две: 2 + 8 и 3 + 7 Прямое решение - взять первое число и проверить его со всеми следующими, затем второе - со всеми после него и так далее. Каждую пару позиций проверяем один раз. Получится: (n − 1) + (n − 2) + … + 1 = n(n − 1) / 2 Раскрываем скобки: n²/2 − n/2. При больших n основной рост задаёт квадрат, поэтому получаем O(n²) Данных стало в 10 раз больше - работы примерно в 100 раз больше Но это сложность конкретного решения. Эту же задачу можно решить за ожидаемое O(n) с помощью хэшмапы (в видео как раз есть) ❗️ И ещё: когда называешь сложность, уточняй, что оцениваешь - среднее время, худшее время или память. Само обозначение Big O не означает «худший случай»  Big O встречается разработке постоянно: Java-коллекции, индексы БД, обработка данных на диске. Пройти файл из n записей один раз - O(n), если обработка записи занимает O(1). Это полезно понимать и за пределами задач с собеседований. Но асимптотика не заменяет обычной логики. Миллиард простых операций на компьютере вполне может выполниться быстрее, чем один поход в сеть на пять секунд. Зависит от операций, железа и того, как выполняется код. Поэтому надо смотреть и на рост числа операций, и на их реальную цену: сколько запросов уходит в БД и сеть, сколько данных читается с диска. Здесь алгоритмы встречаются с архитектурой и system design Важно понимать, как решение поведёт себя при росте данных, и находить реальное узкое место. А то можно долго улучшать цикл, пока всё время съедает один неудачный сетевой вызов 🙃 #хардовая_польза 🧱 - база, уже знал ❤️ - полезно, узнал новое

Запись вчерашнего эфира Изначально не планировали её делать, но решили таки выдать, потому что меня больше 50 человек точно, потом бросили считать, попросили её выдать в силу часовых поясов/занятости вечерней, хренового интернета и прочих уважительных причин Решил заключить сделку с дьяволом вами в закрытом канале: набираем больше 200 🔥, публикую запись, нет - ну нет так нет 🤷‍♂️🤷‍♂️🤷‍♂️ Поэтому, кто хотел запись, залетайте закрытый канал, ставьте реакцию, все зависит только от вас 🔥 А вообще большое всем спасибо, были вместе больше 3 часов, это же офигеть Очень много приятных слов наговорили, я супер заряжен топить дальше, много планов на продвинутые продукты и новые видосы на ютубчик

Перешли к AI: контекст, MCP, скиллы и проверка результата. Залетай разобраться, как всем этим пользоваться → lk.sorokin.school

⌨️ Лезем в код, разбираем и настраиваем вызов Antifraud Залетай на урок по прямой ссылке → lk.sorokin.school

⚡️Стартуем через 15 минут Расскажу, какие технологии точно нужны сейчас и вместе напишем проект Успевай зарегистрироваться по ссылке в закрытом канале

Один платёж. Три сервиса. Несколько способов всё сломать Уже сегодня в 19:00 на открытом уроке в прямом эфире разбираем Payment Platform - проект на Java, Spring, PostgreSQL, Redis и Kafka ⌨️ В нём Payment создаёт и подтверждает платежи, Antifraud проверяет риск по HTTP, а Audit получает события через Kafka и сохраняет историю Сначала покажу, как создаётся и подтверждается платёж, потом полезем в код и посмотрим, что происходит, когда соседний сервис зависает, кэш устаревает, а событие приходит несколько раз Что разберем на конкретных примерах: 🟣 HTTP и таймауты Antifraud отказал в платеже или вообще не ответил - это две разные ситуации. Посмотрим, почему в одном случае сохраняется REJECTED с причиной, а в другом API возвращает 503 и платёж не создаётся 🟣 Hibernate и N+1 Запросили список платежей, а Hibernate полез отдельно загружать их владельцев. Посчитаем реальные SQL-запросы, включим вариант с JOIN FETCH и сравним 🟣 Redis и устаревший кэш В PostgreSQL платёж уже CONFIRMED, а API всё ещё отдаёт NEW. Проверим сценарий с инвалидацией и по логам увидим, откуда приложение берёт данные - из базы или Redis 🟣 Kafka и повторная обработка Платёж подтвердили один раз, а событие прилетело несколько раз. Разберём, как распознать повтор и не записать одно и то же в историю платежа Будем смотреть на код, ответы API, SQL и логи, чтобы можно было проследить, что произошло с конкретным платежом, а не просто поверить, что «ну Kafka там что-то отправила» Отдельно, на схемах, разберём границы микросервисов, API Gateway и Outbox. Затем - как подходить к росту системы: балансировка, репликация и шардинг, какие проблемы они решают и какие ограничения добавляют Будет и блок про AI для обучения и работы: контекст, кодинг-агенты, MCP, скиллы и проверка результата, а в конце соберём маршрут обучения: с чего начинать, что пробовать руками и куда двигаться, если Spring, Redis и Kafka уже знакомы 🔗 Ссылка на регистрацию и всю инфу об уроке найдешь в закрытом канале

Купил один раз, а бонусы получил дважды или как сделать клиента довольным, а разработчика - не очень 🙃 Ты разработал сервис, все круто, классно, выкатил его и случается так, что после покупки он получает из Kafka событие OrderPaid и начисляет бонусы Баланс в PostgreSQL обновился, а потом сервис упал - до фиксации offset, то есть позиции, до которой сообщения обработаны После перезапуска событие приходит снова, бонусы начисляются ещё раз. Акцию «удвоим бонусы» вроде никто не согласовывал, но она уже работает))) При доставке at least once повторы возможны и обработчик должен учитывать, что это событие он уже видел.

😒 : «Ну окей, перед начислением проверю, есть ли eventId в базе»

А если две обработки пересекутся по времени? Обе проверят, обе увидят «такого нет», обе начислят. И проверка как бы была, но толку немного 🤷‍♂️🤷‍♂️🤷‍♂️ Поэтому право обработать событие закрепляем уникальной записью в БД. Например, делаем event_id первичным ключом:

INSERT INTO processed_events (event_id)
VALUES (:event_id)
ON CONFLICT DO NOTHING
RETURNING event_id;

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

😎: «Понял, сначала сохраню отметку об обработке. Потом отдельно начислю»

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

BEGIN
  INSERT eventId
  Если вставка успешна → UPDATE баланса
COMMIT

Либо сохраняются оба изменения, либо оба откатываются, после отката повторная попытка сможет выполнить начисление

🤔: «А может, просто offset раньше зафиксировать, чтобы Kafka не присылала повтор?»

Тогда при падении до коммита БД бонусы не сохранятся, а позиция уже будет отмечена как пройденная. От дубля избавился, обработку потерял - такой сомнительный обмен Поэтому в этой схеме offset фиксируем после коммита БД. Если упадём между ними - событие придёт повторно, но запись с тем же eventId не даст начислить бонусы второй раз Сам eventId при повторе должен оставаться прежним, новый UUID на каждую попытку сломает всю эту затею Подробно эту тему и ей подобные рассмотрим уже завтра, 29 октября, на открытом уроке, разберём код Payment Platform и проверим, как проект справляется с повторными событиями (и не только) Отправим пять копий одного события, посмотрим код consumer, логи и записи в базе, сравним результат с защитой от дублей и без неё 🎁 После эфира заберешь код проекта себе, чтобы запустить его и самостоятельно разобрать, как всё устроено Регистрируйся по ссылке и переходи в закрытый канал - там будет ссылка на эфир

Наняли бы вы самого себя? 🤔 Только давай без «я ответственный, быстро обучаюсь и вообще классный разраб» Представь, что тебе нужно нанять человека, который напишет backend для твоего проекта. Приходит кандидат, по словам и даже по собесу - всё ок, подходит

Вы ему: «Отлично, сможешь сделать создание заказа, сохранение в базу и отправку уведомления?» А он: «Нуууууу, да?..» 🙃

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

Что после этой темы я могу написать сам? Что могу объяснить? А где пока просто повторил за уроком или агентом?

🔜 Чтобы тебе было проще ответить на эти вопросы, жду тебя на открытом уроке 29 октября в 19:00 МСК, в прямом эфире разберём «Современный Java Backend: что знать, уметь и как собрать всё в систему» Пройдём roadmap по основным темам: Spring Boot и HTTP, базы данных и Hibernate, Kafka, Redis, взаимодействие сервисов. Дополнительно поговорим про микросервисы, system design и AI: что нужно понимать, насколько глубоко копать и что пробовать руками ⚡️ И потрогаем Payment Platform - готовую учебную платёжную систему Потыкаем UI, пройдём по коду, посмотрим, как запрос доходит до базы и других сервисов, какие ошибки возникают и как с ними разбираться Хочу, чтобы ты мог честно оценить свою подготовку: вот это уже умею, здесь надо потренироваться, а вот в этом пока не разобрался Кто ещё не зарегистрировался - ссылка на регистрацию лежит в закрытом канале здесь ⬅️

В какой момент изучения Java уже разрешают писать на Java? 🙃 А то сначала надо дочитать книгу, потом разобраться со Spring, но перед этим желательно понять, как он устроен под капотом. А там ещё Hibernate, транзакции, многопоточка… Короче, приложение идёт на ... откладывается, идёт подготовка к подготовке))) Самое бесячее — ты реально учишься: тратишь вечера, разбираешь сложные темы. Но определить, где уже достаточно и пора применять, а где ты пока вообще ничего не понял, — отдельная задача Я сам люблю глубоко закапываться в технические штуки. Но важно ещё понимать, как всё это собирается в работающую систему и что ты уже можешь попробовать руками Потому что отдельно знать Spring, SQL и Kafka — ещё не значит понимать, как из них складывается backend 29 октября в 19:00 МСК проведу открытый урок «Современный Java Backend: что знать, уметь и как собрать всё в систему» ⌨️ Разберём roadmap по Java Backend: что необходимо знать, в каком порядке изучать технологии и что пробовать руками, чтобы из отдельных тем сложилась понятная картина 🟣 Spring Boot и HTTP. Как устроено backend-приложение: куда приходит запрос, что делают контроллеры и сервисы и где находится бизнес-логика 🟣 Базы данных и Hibernate. Что нужно понимать про SQL, работу с PostgreSQL, транзакции и ORM, какие есть подводные грабли 🟣 Взаимодействие сервисов. Как backend общается с другими системами через HTTP и gRPC, когда нужен прямой вызов, а когда — обмен событиями через брокер сообщений 🟣 Брокеры и кеши. Зачем нужны Kafka и Redis, какие задачи они решают и что стоит понимать, прежде чем добавлять их в свой проект В общем базовые темы, но посмотрим на разные ошибки в этих технологиях, которые можно допустить и на какие грабли наступают разработчики, а еще .. Дополнительно поговорим про микросервисы, system design и AI: как всё это связывается в архитектуру, что меняется в работе с кодинг-агентами и куда двигаться дальше И потрогаем код. Разберём Payment Platform — учебную платёжную систему. Посмотрим на неё через интерфейс и ключевые участки кода: проследим путь запроса, обращения к базе, работу кеша и события между сервисами Урок подойдёт тем, кто уже знает основы Java, spring, и работающим разработчикам, которые хотят связать знания и разобраться с пробелами Хочу, чтобы после эфира вместо списка «Spring, Hibernate, Redis, Kafka и ещё 100500 слов» у тебя была связная картина: что делает каждая часть, как они работают вместе и когда их использовать Потому что потратить ещё месяц на обучение легко. Сложнее понять, на что именно его потратить, чтобы наконец сделать то, что раньше не получалось Также на вебинаре презентую новый поток Java Backend и подробно расскажу про программу, обновления и формат обучения Чтобы зарегистрироваться, переходи в закрытый канал — ссылка на регистрацию ждёт ТАМ ⬅️ P.S. подписывайся на канал вебинара, там будут все апдейты)

Штанга всегда будет тяжёлой 🏋️ Есть мысль, которая мне нравится:

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

Ты становишься сильнее, но и поднимаешь уже больше. В работе и жизни часто происходит примерно то же самое Когда я учился в вузе, у меня был осторожный план: сначала диплом, потом стажировка, потом работа. Казалось, вот закончу учёбу - и можно будет нормально начинать Но работать я начал уже на втором курсе И было пиздец как тяжело)) Тяжело готовиться, проходить собесы. На них много спрашивали, как я вообще собираюсь совмещать работу с вузом Потом устроился, и нужно было одновременно выполнять задачи команды и учиться. Перед сессией обсуждать с руководителем, когда меня не будет и как закрою задачи. Учёба почему-то не исчезла после первого оффера 🤷‍♂️ На четвёртом курсе я уже работал сеньором full-time, продолжал учиться и писал диплом. Опыт вырос, задачи стали сложнее, ответственности больше, а диплом всё ещё требовал моего личного участия, ну и всякие лекции и курсовые никуда не делись Поэтому, когда меня спрашивают, можно ли устроиться во время учёбы и всё это совмещать, - да, можно, но придётся заплатить за это временем и силами Не было момента, когда я такой

«Ну все, теперь навсегда легко»

Сначала тяжело найти первую работу. Потом - разобраться в проекте, дальше - самостоятельно лидить эти проекты в команде и так далее Каждый раз появляется следующий вес/уровень Причем даже оставаться на своем уровне требует усилий: меняются технологии, требования, экономическая ситуация. Пока ты ничего не меняешь, вокруг тебя всё продолжает двигаться Вот нейронки много чего упростили. То, на что раньше уходил вечер, сейчас иногда можно сделать за несколько минут. Я сам ими пользуюсь и в команде прошу внедрять Но конкуренция-то никуда не делась 😏 Эти инструменты появляются и у других, ты конкурируешь с человеком, который тоже умеет ими пользоваться Человек + инструмент против человека + инструмент Получить код стало проще, а понять, что вообще нужно написать, выбрать решение, проверить результат и отвечать за последствия всё ещё кому-то надо Сервис тормозит, агент предлагает добавить кеш. Код он тебе напишет, а выяснить, что именно тормозит, какие данные можно кешировать и что будет после их изменения, всё равно придётся Просто меняется набор навыков, которые нужно развивать. Где-то работы стало меньше, где-то теперь можешь взяться за задачу, до которой раньше вообще не добирался 📌 И эта история далеко не только про разработку Между тем, что ты хочешь, и тем, что у тебя есть, часто стоит действие, которое нужно сделать Неприятное, сложное, с непонятным результатом. Отправить резюме. Пройти собес. Признаться, что чего-то не понимаешь. Попросить помощи Если бы это было так же легко и приятно, как полистать TikTok, ты бы, скорее всего, уже сделал)) В кризис бывает тяжелее, когда экономика растёт, какие-то возможности даются легче. Но рассчитывать на период, когда вообще всё станет просто, я бы не стал Со сложностью придётся учиться жить Разбирать большую задачу на части, менять план, учиться, иногда снижать нагрузку и восстанавливаться. Не требовать от себя, чтобы каждый следующий шаг обязательно давался спокойно и уверенно Штанга тяжёлая. Ты можешь сомневаться, уставать и иногда (или не очень) тебе будет трудно/сложно/тяжело It’s okay to not be okay 🤷‍♂️🤷‍♂️🤷‍♂️

Открыл проект → увидел 300 тысяч строк → закрыл проект 🙃 Расскажу, как сам разбирался в новых проектах и что советую ребятам, которые приходят на первую работу У меня был такой опыт с платёжной системой: большой проект, куча сервисов, модулей, связей. Сначала вообще непонятно, где что происходит. При этом интересно разобраться, как всё это работает Но если просто открывать классы подряд, через полчаса уже забываешь, что искал. А тебе ещё задачу дали - что-нибудь небольшое поправить в процессе платежа. Небольшое-то небольшое, осталось понять, где Я обычно брал один конкретный сценарий и проходил его целиком, например, создание платежа Нашёл куда приходит запрос → посмотрел, что передали → где проверяются данные → куда дальше уходит вызов Потом - бизнес-логика: какие проверки, откуда берутся данные, как меняется статус платежа. Дошёл до записи в БД, посмотрел, отправляется ли событие в Kafka и кто его потом читает 🤙 И у тебя всё это время есть конкретный вопрос в голове:

«Что происходит, когда пользователь создаёт платёж?»

В системе таких процессов может быть ещё несколько десятков. Но сейчас ты разбираешь один: раскладываешь на шаги, смотришь, как они связаны, отмечаешь непонятные места Можно по ходу набросать схему: сюда пришёл запрос, здесь сходили в другой сервис, тут сохранили, отсюда отправили событие. С такой схемой потом и вопросы команде задавать проще Особенно помогает конкретная задача внутри этого процесса. Нужно добавить проверку - начинаешь выяснять, какие уже есть и где они живут. Нужно изменить статус - смотришь, кто его читает и что от него зависит По дороге начинаешь понимать гораздо больше, чем только свой участок: какие сущности есть, как разделена логика, куда сервис обращается за данными, как здесь вообще принято писать код И обязательно задавай вопросы команде. В коде видно, как сделали, а вот почему сделали именно так, там может вообще не быть. Возможно, это ограничение соседнего сервиса или временное решение, которому уже 5 лет. Такая, вот очень стабильная временность 😎 Разобрал создание платежа? Берёшь возврат. Потом ещё один сценарий, начинаешь узнавать общие участки, понимать, где искать нужную логику и к кому идти с вопросами Эффективно изучить все 300 тысяч строк за один заход у тебя не получится. А после одного разобранного процесса уже есть за что зацепиться: ты понимаешь часть устройства системы и можешь использовать это в следующей задаче. Так и собирается общая картина Это мой совет тем, кто только выходит на работу и немного охреневает от размеров проекта))) Старички, накидайте ещё базы новичкам: что помогало вам быстрее разобраться в проекте, понять требования и влиться в команду? А если сейчас кто-то проходит испыталку или готовится к первой работе - пишите, что вызывает вопросы 👍