Павел Сорокин | Java
Kanalga Telegram’da o‘tish
О том как стать и быть Java разработчиком Обучение по Java до оффера: https://sorokin.school По рекламе и сотрудничеству: @pave1ss или sorokincompany@rambler.ru
Ko'proq ko'rsatish8 284
Obunachilar
+124 soatlar
+537 kunlar
+35130 kunlar
Ma'lumot yuklanmoqda...
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Iyul '26
Iyul '26
+124
0 kanalda
Iyun '26
+532
0 kanalda
Get PRO
May '26
+588
0 kanalda
Get PRO
Aprel '26
+527
1 kanalda
Get PRO
Mart '26
+581
0 kanalda
Get PRO
Fevral '26
+365
0 kanalda
Get PRO
Yanvar '26
+404
0 kanalda
Get PRO
Dekabr '25
+392
1 kanalda
Get PRO
Noyabr '25
+710
0 kanalda
Get PRO
Oktabr '25
+613
0 kanalda
Get PRO
Sentabr '25
+521
0 kanalda
Get PRO
Avgust '25
+281
0 kanalda
Get PRO
Iyul '25
+226
0 kanalda
Get PRO
Iyun '25
+277
0 kanalda
Get PRO
May '25
+414
1 kanalda
Get PRO
Aprel '25
+275
0 kanalda
Get PRO
Mart '25
+215
0 kanalda
Get PRO
Fevral '25
+207
1 kanalda
Get PRO
Yanvar '25
+240
0 kanalda
Get PRO
Dekabr '24
+356
17 kanalda
Get PRO
Noyabr '24
+174
0 kanalda
Get PRO
Oktabr '24
+410
5 kanalda
Get PRO
Sentabr '24
+555
7 kanalda
Get PRO
Avgust '24
+406
2 kanalda
Get PRO
Iyul '24
+246
0 kanalda
Get PRO
Iyun '24
+107
0 kanalda
Get PRO
May '24
+219
1 kanalda
Get PRO
Aprel '24
+91
0 kanalda
Get PRO
Mart '24
+491
1 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 11 Iyul | +3 | |||
| 10 Iyul | +5 | |||
| 09 Iyul | +10 | |||
| 08 Iyul | +14 | |||
| 07 Iyul | +12 | |||
| 06 Iyul | +9 | |||
| 05 Iyul | +16 | |||
| 04 Iyul | +17 | |||
| 03 Iyul | +21 | |||
| 02 Iyul | +11 | |||
| 01 Iyul | +6 |
Kanal postlari
Как разобраться в многопоточности ОТ и ДО - ПОЛНЫЙ ROADMAP
Главная проблема изучения многопоточки в том, что её вообще непонятно как учить, и обычно всё выглядит так ⤵️
Ты берёшь рандомные статьи, открываешь, читаешь про
synchronized, потом видишь отсылку на JMM, открываешь JMM, там happens-before, гуглишь happens-before - и через два часа у тебя 47 вкладок, полная каша в голове и желание закрыть ноут и пойти поспать
Чтобы эту проблему решить - я собрал для тебя Базу Знаний Многопоточки. Вот что внутри:
• Видео-урок, который даст понимание ЧТО, В КАКОМ ПОРЯДКЕ и ДО КАКОЙ ГЛУБИНЫ учить
• Полная структура изучения со всеми темами, чтобы идеально подготовиться к собесам на миддла и выше
• Конспект к уроку и 2 дополнительных видео по изучению многопоточности (теория + лайфкодинг)
Чтобы получить урок+конспект бесплатно - подписывайся на мой канал и запускай бота, он сразу пришлёт тебе урок сообщением ⬇️| 2 | Серебряная пуля и perfect pick
У нас часто есть ощущение, что где-то существует правильный ответ
Правильная архитектура. Правильный стек. Правильная база данных. Правильный момент, когда идти на собес. Правильный кандидат. Правильный партнер.
😎 Правильное решение, после которого можно наконец-то спокойно действовать
Но проблема в том, что в жизни почти никогда нет идеально правильных и неправильных ответов
Кажется, что все вокруг знают, как жить, как строить бизнес, как проектировать архитектуру, как выбирать людей и как принимать решения. Но если честно посмотреть на реальность - никто до конца не знает, как «на самом деле правильно»
Мы просто принимаем достаточно хорошие решения, чтобы оно работало
И это очень видно в разработке. Ты заходишь в старый проект, видишь сервис, который выглядит криво, косо, странно, местами вообще просто насрали в репозиторий
А потом выясняется, что сервису 20 лет. Он пережил 5 команд, 3 переписывания, 14 бизнес-поворотов, миграцию на облака и так далее
В моменте никто не знал, что этот кусок кода будет жить 10 лет. Просто тогда приняли такое решение. В том контексте оно было нормальным. Потом контекст изменился, система выросла, решение обросло зависимостями, и теперь оно выглядит как «исторически сложилось»
Ну да, кривое. Ну да, косое. Но оно работает. И бизнес на этом живет
Очень много вещей в мире сделаны не идеально. Они сделаны достаточно хорошо, чтобы выполнять свою функцию. Но мы часто хотим серебряную пулю 💩
Идеальное знание. Идеальное решение. Идеальный выбор. Идеальный момент для действия
Это fallacy of perfect pick - ожидание, что где-то есть идеальный выбор, и если мы достаточно долго подумаем, сравним, почитаем, посмотрим ещё одно видео, спросим ещё одного умного человека, то найдём тот самый вариант без риска, боли и последствий
Но цена бесконечного выбора часто выше, чем разница между «очень хорошим» и «идеальным»
Например, человек думает, когда идти на собес. Ему кажется, что надо ещё подучить многопоточку, потом Spring, потом Kafka, потом System Design, потом ещё чуть-чуть алгоритмы, потом пройти 3 mock interview, потом ещё раз повторить Java Core
И вроде все логично. Он готовится 😇
Но после какого-то момента это уже не подготовка, а форма избегания. Потому что пока ты готовишься - ты как будто контролируешь ситуацию. А когда пошёл на собес - рынок уже даёт тебе обратную связь. И она может быть неприятной.
То же самое с выбором кандидата. Можно бесконечно искать идеального человека: умного, ответственного, харизматичного, с опытом, без странностей, чтобы сам себя онбордил, сам все делал и желательно еще не хотел денег
Но такого может не быть
И тогда нормальная стратегия - не искать мифического единорога, а достаточно быстро найти достаточно хорошее решение
То же самое с архитектурой. Можно месяцами выбирать между Kafka и RabbitMQ … Короче понятно
🖕 Идеальных решений не существует. Эту старую пословицу «лучшее - враг хорошего» придумали не просто так
Можно бесконечно впадать в прокрастинацию и откладывать выбор с мыслью:
«Я ещё недостаточно готов», «я сейчас плохо себя чувствую», «через неделю буду знать лучше», «с понедельника начну новую жизнь», «в будущем я наконец-то приму правильное решение»
Но в будущем ты тоже не будешь обладать идеальным знанием
Идеальный момент не наступит. Серебряная пуля не прилетит. Таблетки «принял и всё стало понятно» не существует
Нужно просто продолжать ДЕЛАТЬ НЕИДЕАЛЬНО ☹️
Да, это пиздец как больно. Больно видеть и думать «я мог бы лучше», «а можно было бы еще это и это», «а что если». Но надо сделать не идеально, местами криво, но достаточно нормально, чтобы оно работало. Это лучше, чем откладывать и не делать вообще | 1 937 |
| 3 |  Пока работаешь на одном проекте, очень быстро привыкаешь к его ограничениям
Какие-то таски начинаешь решать на автомате, потому что похожие вещи писал десятки раз: код работает → фичи выкатываются → з/п на карту падает
Из-за этого перестаешь сталкиваться с задачами, где нужно думать над эффективностью решения, а не просто сделать так, чтобы оно работало.
😆 Как раз этим летом появился движ, где такую среду можно получить — CodeRun Summer Challenge
Главная особенность челленджа в том, что здесь в зачёт идёт performance engineering - чем быстрее и эффективнее работает решение, тем выше ты поднимаешься в лидерборде. По сути, это тот же подход, который используют на тех.собесах в крупных компаниях
Что по формату:
• 15 задач от легких к хардовым
• новые задачи открываются волнами по 5 штук каждые 5 дней
• общий зачёт и отдельные лидерборды по каждому языку
Стартовать можно в любой день до 17 июля, так что если ты начинающий Java-разработчик, то это идеальный полигон, чтобы набить руку, а если опытный - хороший способ проверить, не заржавели ли скиллы 🤔
Призы:
• топ-1 по каждому языку получает мерч-пак CodeRun
• топ-3 общего зачёта - коллекционный лего-набор
• топ-200 общего зачёта - скип отборочного контеста и пробное интервью
По сути, это еще одна возможность потренироваться на задачах, где важно не просто получить правильный ответ, а найти действительно эффективное решение. А если попадешь в топ - можно еще и попробовать свои силы в Яндексе. Поэтому участвуем тут.
Накидай 🔥, если интересно, и напиши в комментах, какие задачи показались интересными, мб разберу какие-нить в видосах | 2 444 |
| 4 |  Как разобраться в многопоточности ОТ и ДО - ПОЛНЫЙ ROADMAP
Главная проблема изучения многопоточки в том, что её вообще непонятно как учить, и обычно всё выглядит так:
Ты берёшь рандомные статьи, открываешь, читаешь про synchronized, потом видишь отсылку на JMM, открываешь JMM, там happens-before, гуглишь happens-before - и через два часа у тебя 47 вкладок, полная каша в голове и желание закрыть ноут и пойти поспать
Чтобы эту проблему решить - я собрал для тебя Базу Знаний Многопоточки. Вот что внутри:
• Видео-урок, который даст понимание ЧТО, В КАКОМ ПОРЯДКЕ и ДО КАКОЙ ГЛУБИНЫ учить
• Полная структура изучения со всеми темами, чтобы идеально подготовиться к собесам на миддла и выше
• Конспект к уроку и 2 дополнительных видео по изучению многопоточности (теория + лайфкодинг)
Чтобы получить урок+конспект бесплатно - подписывайся на мой канал и запускай бота. Бот проверит подписку и сразу после этого пришлёт тебе урок сообщением ⬇️ | 719 |
| 5 | Когда изо дня в день фигачишь однотипные задачи, мозг реально перестает включаться. Таски закрываются, все работает, но роста, что закономерно, нет 🙄
И вот в такие моменты хорошо бы получить пинок: хоть от руководства, хоть от себя самого. Иногда достаточно просто на время нырнуть в другую среду, где задачи просто другие и уровень сложности повыше.
Как раз этим летом появился движ, где эту среду можно получить — CodeRun Summer Challenge.
Отличается этот челлендж по решению задачек тем, что тут в зачёт идёт performance engineering — чем быстрее и эффективнее твой код, тем выше ты в лидерборде. Фактически модель поведения, которую от тебя ждут на техноинтервью в компаниях
Как всё устроено:
— 15 задач от лёгких к хардовым
— выходят волнами по 5 штук каждые 5 дней
— общий зачёт и 11 языковых лидербордов
Стартовать можно в любой день до 17 июля, так что если ты начинающий Java-разработчик, то это идеальный полигон, чтобы набить руку, а если опытный — хороший способ проверить, не заржавели ли скиллы 🤔
Призы:
— топ-1 по каждому языку получает мерч-пак CodeRun
— топ-3 общего зачёта — коллекционный лего-набор
— топ-200 общего зачёта — скип отборочного контеста и пробное интервью
Решаешь задачи в своё удовольствие, прокачиваешь навыки оптимизации, алгоритмического мышления и performance engineering, а бонусом получаешь возможность попробоваться в Яндекс. Да и проверить себя в условиях, приближенных к реальным, где важна каждая миллисекунда — дорогого стоит. Поэтому участвуем тут.
Накидайте 🔥, если интересно, и напишите в комментах потом какие задачи показались интересными, мб разберу какие-нить в видосах | 1 836 |
| 6 |  Ну что, часть из вас оказалась права: я записал подкаст с крутейшим Владимиром Балуном - бывшим тимлидом Яндекса и основателем школы Balun.Courses 😎
Когда все вокруг кричат, что нейросети скоро заменят программистов, возникает вопрос:
Почему тогда сильные разработчики до сих пор стоят так дорого?
Поговорили не про очередные промпты и «как использовать ChatGPT», а про вещи, которые действительно определяют карьеру разработчика:
🟣почему фундаментальные знания становятся только ценнее с развитием ИИ
🟣 что на самом деле происходит с IT-образованием
🟣 зачем сегодня нужны преподаватели, если ответы можно получить за секунду
🟣стоит ли сейчас вообще входить в IT
🟣какие навыки останутся востребованными через 5–10 лет
Получилось довольно легко и я бы сказал, воодушевляюще 🥴
Если переживаешь, что же будет с индустрией в ближайшем будущем 😱, определенно, будет полезно
Смотреть на YouTube: youtube.com/watch?v=XlGOWZoZAOo | 4 236 |
| 7 |  И сигну от меня получаааеет: @Vonaski 😎 | 3 751 |
| 8 |  Самые сильные люди, с которыми мне доводилось работать, почти никогда не делают только то, что написано в задаче🙃
И это одна из самых ценных вещей в работе - когда человек делает чуть больше, чем его просили
Но не в формате переработок, ночных созвонов и прочего трудового героизма. А просто когда ему становится интересно докрутить задачу дальше 😎
Буквально недавно поставил дизайнеру вполне конкретную задачу - сделать первый экран сайта. Даже в голове уже представлял, что примерно хочу увидеть на выходе. Через какое-то время он присылает результат, и я понимаю, что он сделал не совсем то, что я ожидал. В хорошем смысле
Потому что помимо самой то задачи, он докрутил идею ещё на несколько шагов вперёд. Сам придумал концепцию, сам её реализовал, добавил детали, которые я не описывал и в итоге результат получился сильнее, чем моя первоначальная задумка
И я поймал себя на мысли, что практически всё, что по-настоящему изменило мою жизнь, происходило похожим образом 🙂
Когда я снимал видосы на YouTube, мог просто сделать очередное видео "Как написать ТГ-бот на Java", выложить его и пойти дальше. Но самые большие результаты всегда приходили после тех видео, в которые хотелось вложить чуть больше, чем требовалось.
Или с обучением, когда можно было ограничиться поверхностным разбором темы, а я сидел и ещё несколько часов копался в материалах, искал примеры, переписывал объяснение, потому что хотелось сделать лучше
Для этого даже есть хорошее слово - оверперформ
Не в корпоративном смысле, где тебя пытаются заставить работать за троих. А в нормальном, человеческом, когда дали задачу на один уровень, а ты посмотрел на неё на два уровня глубже
И именно такие люди потом чаще остальных оказываются в самых интересных проектах с интересными зарплатами. Просто потому, что они регулярно делают намного больше, чем от них ожидали | 4 239 |
| 9 |  Почему retry может положить систему? 😔
В какой-то момент почти любой сервис начинает ловить таймауты к соседям. Где-то сеть моргнула, где-то зависла база, где-то просто не повезло.
Первая реакция обычно максимально логичная: добавим пару ретраев и станет стабильнее
Не ответил на запрос - попробуем ещё раз. Если всё идемпотентно, то вообще без риска. Но как только одному из сервисов становится реально плохо, вся эта история начинает работать в обратную сторону
👀 Представь обычную цепочку: Order Service ходит в Payment Service. Платёжка начала тормозить, не умерла, но отвечает по 3–5 секунд, а потом вообще перестаёт. Order такой:
«Окей, не ответил - попробую ещё раз, не получится, то повторю снова»
И так делает не один запрос, а сразу вся система. В этот момент ретраи превращаются из «страховки» в «давай добьём всё окончательно»
Нагрузка растёт → сервис отвечает ещё медленнее → растёт количество таймаутов → таймауты рождают новые ретраи
🫢 Классический замкнутый круг, где система сама себе ухудшает состояние. Обычно в этот момент вспоминают про exponential backoff. Типа не долбим сразу, а ждём: сначала секунду, потом две, потом четыре. Плюс добавляем jitter, чтобы все клиенты не проснулись одновременно и не прилетели в одну и ту же миллисекунду
Это действительно лучше. Но есть одна неприятная деталь, о которой редко думают: Backoff не уменьшает нагрузку, он её откладывает
Если сервис быстро восстановился - всё красиво, запросы разъехались по времени и он успел их переварить.
Но если даунтайм длинный, то все эти отложенные ретраи всё равно прилетят. Просто чуть позже и более плотной волной
И вот ты уже в ситуации, где баг пофиксили, релиз откатили, а система всё равно не оживает 😐
Потому что на неё одновременно падает обычный трафик, накопленные ретраи и ещё пользователи, которые сами жмут «повторить». Сервис снова захлёбывается, ловит таймауты, генерит новые ретраи - и поехали по второму кругу
🤔 Это то самое состояние, когда триггер уже убрали, а система всё равно не может восстановиться, потому что сама себя держит под нагрузкой. В этот момент приходит довольно неприятное осознание:
ретраи - это не всегда про надёжность.
Иногда это про то, как замедлить восстановление в несколько раз
🟣И один из нормальных подходов - retry budget
Идея простая: ретраи разрешены, но ограничены, например, не больше 10% от успешных запросов. Пока сервис отвечает нормально, бюджет есть, можно ретраить флапы. Как только он начинает сыпаться, успешных ответов становится мало, бюджет быстро заканчивается, и ты автоматически перестаёшь накидывать сверху дополнительную нагрузку
❗️Иногда это дополняют retry circuit breaker’ом - если процент ошибок слишком высокий, ретраи временно вырубаются вообще. Потому что в этот момент лучше быстро получить ошибку, чем ещё сильнее убить сервис и затянуть восстановление.
И тут важно понять, retry - это нагрузка, которую ты берёшь в долг у системы. Пока всё хорошо - это почти незаметно и даже полезно. Когда всё плохо - этот долг внезапно приходит с процентами.
🆗 Поэтому хороший retry - это всегда про ограничения, контроль и понимание, в каком состоянии находится сервис.
❌ А плохой retry - это когда система уже лежит, а ты продолжаешь верить, что следующая попытка точно сработает
Накидай 🔥, если было полезно 😎 | 4 105 |
| 10 | Самая дорогая ошибка разработчика - перепутать комфорт с ростом
Я уже рассказывал о знакомом из Ижевска, перед которым стоял выбор его дальнейшей карьеры. В комментах у многих начали расходиться мнения, что ему стоит лучше сделать, и это натолкнуло меня на определенные мысли
Очень многие разработчики думают, что уперлись в потолок потому, что им не хватает мотивации, дисциплины или они мало изучают
Я замечал это и на себе, и на своём окружении. Человек может быть сильным разработчиком, работать по 8 часов в день, закрывать задачи, получать хорошие отзывы. Но при этом через год обнаруживает, что особо-то никуда не сдвинулся 🙄
Самый простой способ это проверить - попробовать вспомнить, что нового появилось в твоей работе за последний год
Не новую версию библиотеки или фикс очередного бага, а именно что-то новое для себя:
• новая зона ответственности
• новое архитектурное решение
• сложная проблема, над которой пришлось поломать голову
Если таких вещей не было - это повод задуматься
Когда-то я заметил, что многие задачи начал делать практически на автомате
Получаешь таску → понимаешь, как решать → пишешь код → закрываешь тикет
С одной стороны это приятно и работается спокойно, а с другой - именно в этот момент рост часто начинает замедляться
Когда растешь как разработчик, довольно часто чувствуешь себя немного глупым, потому что постоянно сталкиваешься с тем, чего еще не знаешь: незнакомые сервисы, новые проблемы в проде, новая зона ответственности и так далее
Это не самые комфортные периоды работы, зато именно после них обычно понимаешь, что скиллы стали круче
Мне кажется, одни из самых полезных вопросов, которые можно себе периодически задавать это что-то вроде:
• Что я спроектировал за последний год?
• На какие решения я реально повлиял?
• Чему научился, чего не умел раньше?
Если трезво отвечать на эти вопросы, то становится понятно, что зачастую текущий проект уже отдал тебе все, что мог дать. И тут только 2 пути:
• надеяться на то, что кто-то напишет и предложит проект по круче
• самому искать возможности для роста
И второй, естессно, правдоподобней и куда быстрее
Накидай 🔥, если согласен и как обстоят дела с твоим потолком - уже достиг его или есть куда расти? | 4 285 |
| 11 |  Готовлю видос-подкаст новый с классным, с сильным известным разработчиком 😎
Кто первый отгадает, кто это - сделаю для него по приколу СИГНУ😁 (кто ещё помнит, что это вообще такое, ахахавха) | 4 280 |
| 12 | Принёс вам 3 мысли про ИИ с конференции Mobile Runtime
Чекнул доклад у Артура Власова про то, как они ИИ в разработку внедряли. Спойлер: он отвечает ровно на те вопросы, которые мне постоянно задают:
1. Стоит ли бояться, что AI меня заменит?
Они честно посчитали по тикетам, коммитам, строкам кода насколько ускорились разработчики. Ответ: 10–20%, у кого-то 30. Никакого «в два раза быстрее»
Потому что с подходом AI-first блокером становится твой собственный мозг. Запустить трёх агентов параллельно легко. А вот удержать в голове три задачи разом, переключаться между ними и проверять за каждым почти невозможно
По сути всё та же мысль - надо быть сильным разрабом, без базы ИИшка не поможет
2. Насколько активно внедряется AI в современной разработке?
Вот это я, как человек, который сам учится руководить, выписал жирным. Они смотрели десятки команд в Яндексе. У кого-то внедрение под 100%, у кого-то 20%. И процент внедрения ВСЕГДА напрямую коррелировал с отношением тимлида
Если лид мыслит «деды руками писали, и я буду», то вся команда тоже будет думать «ну ладно, тоже не будем». Так что внедрение пока медленное, но явно видно, что С-лвлам хочется побыстрее, так что вы тоже не откладывайте изучение агентов
3. Про собесы
Из зала спросили: раз код руками всё реже пишут, может, пора собесы переделать - проверять не «напиши алгоритм», а умение работать с нейронкой?
Ответ мне ОЧЕНЬ понравился. С одной стороны они начали экспериментировать в эту сторону, и это хорошо. С другой они в компании всё ещё хотят, чтобы человек шарил, потому что отвечает за результат по-прежнему он, а не агент
Ну а как вы знаете у меня ровно такое же видение собесов
Ещё был прикольный вопрос «не выгорает ли команда, когда агенты делают их работу лучше», ответ тоже порадовал: пока мы думаем и отвечаем за результат - умные люди не пропадут
Вопрос только в том, попадаешь ли ты в их число)) | 5 014 |
| 13 | Я писал бы объяснительную начальнику смены на соляной шахте, а не код и новый офигенный продукт, если бы чуть меньше ботал информатику ☹️
Когда приезжаю в свой маленький родной город, очень сильно чувствую контраст в жизни
Когда живешь там на постоянке - тебе кажется, что все ОК. Заводы, серость, панельки, работа 25/8 - будто бы норма. Но потом уезжаешь в город по крупнее и начинаешь видеть другой мир и смотреть на всё совсем иначе 🙄
Тогда я просто представить не мог, насколько сильно среда влияет на твой потолок мышления
Дофига моих сверстников вообще не думали ни про вышку, ни про переезд. Многие даже в 10 класс не пошли и просто остались жить там же. Они не были тупыми или проблемными, они просто не видели для себя другие сценарии в жизни
Я сам тоже лет до 15-16 особо не понимал, что делать дальше. Мне нравились математика и информатика, но глобально я просто плыл по течению:
«Да потом разберусь», «Еще 2 года есть», «В 11 классе что-нибудь придумаю»
На ОГЭ хотел сдавать химию и обществознание, просто потому что «ну вроде норм вариант, люди сдают». Но тогда меня образумила моя учительница, благодаря которой я вообще пришел в айтишку
Я решил попытаться выжать максимум из всего 😎 , убрал ненужные предметы и начал жестко готовиться к информатике
Результаты вы уже знаете :)
Но я до сих пор помню первые дни в Питере - когда понял, что мир устроен совсем не так, как мне казалось. Что те правила, по которым живут вокруг только у них в голове
Сейчас я стараюсь специально ломать свою картину мира: общаться с теми, кто думает иначе, лезть в темы, которые кажутся «не моими» и так далее
Потому что знаю: как только перестаёшь это делать - ты снова оказываешься в своём маленьком городе. Только теперь он у тебя в голове | 4 673 |
| 14 |  Circuit Breaker Pattern: как не добить сервис, который уже лежит
Мы чаще всего работаем с распределенной системой, и постоянно случаются проблемы - лег смежный сервис, ресурсы закончились, коннекты к базе уперлись, всплеск трафика, уборщик случайно задел кабель и отключил ДЦ от питания
Типичная ситуация:
«Мы просто кинем запрос в другой сервис по HTTP»
А потом этот сервис начинает отвечать не 100 мс, а 5 секунд. Потом вообще перестаёт отвечать. И если наш сервис продолжает стучаться в падающий сервис, то может быть ряд проблем из-за этого
1️⃣ Мы своими руками добиваем бедолагу
Сервис уже лежит, а мы такие: «Ну-ка, вставай» и добиваем его своими ретраями сверху. В итоге очередь запросов у него растет, нагрузка на него растет. Он пытается рестартануть и мы его снова добиваем
2️⃣ У нас забивается пул потоков
Пока мы ждем долгого ответа, у нас самих висят потоки и забиваются connection pool’ы. И все это время пока потоки висят - новые запросы-то не обрабатываются
И теперь наши клиенты начинают падать по timeout’ам
В итоге в системе один сервис упал, а через пару минут уже лежит вся система. Это называется каскадный сбой. Отказ одного компонента начинает приводить к отказам других частей
Например:
Order Service → Payment Service → Bank API
Если Bank API начал тупить, Payment Service ждёт. Order Service ждёт Payment Service. Пользователь ждёт Order Service 😱😱😱
❗️При таких ситуациях лучше вообще НЕ ходить по сети во внешний сервис, если мы точно знаем, что ему плохо
Если случайно упал один запрос из 1000, например сеть оборвалась, то это ОК, просто погрешность → просто делаем retry. Но если падает 50 из 100 запросов, то сервису явно плохо и нужно подождать его восстановления
🟪 Circuit Breaker - это паттерн, который временно блокирует вызовы к нестабильному сервису, если тот начал часто падать или тормозить
По сути это просто предохранитель, который вырубает трафик, если замечает сбой
У Circuit Breaker обычно три состояния
🟣Closed - всё нормально. Запросы проходят во внешний сервис, а breaker просто считает кол-во ошибок
Order Service → Payment Service
🟣 Open - сервис явно болеет. Breaker «размыкается» и больше не пускает запросы во внешний сервис. Сразу возвращается ошибка, нет похода в сеть
❗️ Мы не тратим ресурсы на заведомо мертвый вызов и не добиваем сервис, который уже лежит
🟣Half-Open - тестовый режим
Через некоторое время breaker пропускает несколько пробных запросов. Если они успешные - возвращаемся в Closed. Если опять ошибки - обратно в Open
Пример состояний:
Closed → много ошибок → Open
Open → подождали → Half-Open
Half-Open → успех → Closed
Half-Open → ошибки → Open
Все эти переходы настраиваются. Мы сами задаем, какой процент ошибок считать критичным, сколько запросов смотреть в окне, сколько держать breaker в Open и сколько пробных вызовов пустить в Half-Open
🤔 А что делать, если сервис упал?
Ответ: деградировать 🙃
Систему стоит изначально проектировать с учетом, что запрос может отвалиться. Почти всегда лучше ответить хоть как-то, чем не ответить никак.
Что можно делать:
• Просто сказать клиенту «извини, вот держи жабу 500»
• Возвращать последний известный корректный результат, который система может вернуть из кэша LKG (last-known-good)
• Возвращать заглушки или успешно принимать запрос, но обрабатывать его позже асинхронно.
👉 Circuit Breaker часто используют в связке с retry паттерном
Retry: «попробуй ещё раз»
Circuit Breaker: «хватит пробовать, чудик»
Retry полезен при кратковременных сбоях: сеть моргнула, случайный timeout. Но если сервис реально лежит, retry только увеличит нагрузку
Поэтому нормальная схема обычно такая: timeout, ограниченный retry с backoff, circuit breaker и fallback.
❓ На собеседованиях по этой теме часто задают такие вопросы:
• что такое Circuit Breaker?
• какие у него состояния?
• зачем нужен Half-Open?
• чем он отличается от Retry pattern?
• что такое fallback?
• как он защищает от каскадных сбоев?
Накидай 🔥, если рассказать больше о паттернах, а в комментах напиши, какие из них вызывают больше всего вопросов | 4 168 |
| 15 |  У моего знакомого произошла интересная история с неочевидным выбором, делюсь 👇
Он сеньор, который работает в компании N и живёт в Ижевске на полной удалёнке. У него ЗП 200.000 рублей, он сильный разраб, и компания сама предложила ему повышение - стать тимлидом
Он подумал, что это интересный трек развития и пошёл обсуждать новые условия, думая
"Ну где-то 250к наверное предложат, в целом норм, да и есть интерес поучиться скиллу управления"
Каково же было его удивление, когда ему предложили поднять ЗП на... 8.000 рублей (мысль "Чтобы расти в бабках надо менять работу, а не думать про рост на текущей" ещё никогда не была так актуальна)
Он тогда взял неделю на подумать, и в конце недели почти согласился, как вдруг...
Пришла другая команда и сказала: "Не, Вась, ну какие 8 тыщ, давай кароче к нам в Мск, ЗП 350к будет, но в офис надо гонять минимум 3 раза в неделю"
И тут у него встал выбор из 3х треков развития событий:
1 - Переехать в Мск, но с учетом аренды получать по сути на 80.000 рублей больше и без удалёнки
2 - Согласиться стать тимлидом на том же месте с ростом по ЗП на 8.000 в месяц
3 - Ничего не менять
Мне эта история показалась крайне занимательной, так что вопрос к вам - какой выбор вы бы сделали?
Я вот за первый варик, но интересно общественное мнение, проголосуйте реакциями:
🔥- первый
❤️ - второй
👍 - третий | 3 733 |
| 16 |  Собрал в один пост то, что ты гуглишь перед каждым собесом 🗒
Это подборка полезных постов на задачки с собесов, теоретическую базу и алгосы
1. Что такое идемпотентность и как реализовать её на практике
2. Как устроены транзакции в целом + задачка на них с собеса
3. Twelve-Factor App - 12 практик, которые делают облачные приложения переносимыми предсказуемыми и масштабируемыми
4. API Gateway - как он устроен и зачем он нужен
5. Чем HTTP/2 отличается от привычного HTTP/1.x
6. Почему виртуальные потоки, корутины и горутины - это гениальное инженерное решение?
7. Три задачки с собесов в 2026 году
8. Задача на многопоточность с собеса в ФинТех
9. База: чем отличается конкурентность от параллелизма
10. Шардирование - зачем оно надо и как его реализовать на практике
11. Многопоточка - она везде
Приятного изучения:)
А чтобы быстро возвращаться к нужным вопросом и не копаться в канале, я сделал хештэг #хардовая_польза - буду все хардовые посты им помечать | 5 364 |
| 17 |  Лишился подкаственной девственности 🤨
Моим первым стал Макс Аверин - основатель @interview_hustlers
У нас на двоих опыт помощи 400+ студентам со вкатом/ростом по грейду в IT, поэтому темы для разговора нашлись быстро:
• Как бы мы заходили в IT в 2026 без коммерческого опыта (и почему скиллкоробка делает свою работу... хорошо?)
• Влияние AI на рынок трудоустройства и что сейчас реально надо знать (алгосы 🍷)
• За какой срок сейчас реально вкатиться? (меньше, чем тебе кажется и больше, чем обещает рынок)
• Как эффективно обучаться в эпоху AI (и причём тут Жигули)
• Рабочие фишки-советы-лайфхаки по трудоустройству здесь и сейчас
• Качай софты или сдохни
Суммарно вышло почти на 1.5 часа - это реально ёмкая must watch выжимка для тех, кому сейчас актуальна тема трудоустройства
🖤 Приятного просмотра - youtube.com/watch?v=9w07TKhSu6o | 5 165 |
| 18 |  Transactional Outbox Pattern: как не потерять событие между БД и Kafka
Есть классическая backend-задача. Cоздаем заказ, сохраняем его в БД и хотим отправить событие в Kafka:
Наивно это выглядит так:
@Transactional
public void createOrder(CreateOrderRequest request) {
Order order = orderRepository.save(new Order(request));
kafkaTemplate.send("order-created", new OrderCreatedEvent(order.getId()));
}
И тут есть ряд проблем
База данных и Kafka - это две разные системы. Транзакция в PostgreSQL не управляет Kafka
Kafka не знает, что происходит в транзакции PostgreSQL. А значит, “сохранить заказ” и “отправить событие” не являются одной атомарной операцией 🙃
А еще транзакции должны быть короткими. Пока транзакция открыта, она держит connection к БД, что может стать боттлнеком. Если внутри транзакции делать сетевой вызов в Kafka или внешний сервис, и он подвиснет, у тебя подвиснет вся транзакция. А потом connection pool забьется и новые запросы будут висеть, ждать свободный коннекшн
В общем, это плохой паттерн в транзакции делать какую-то долгую операцию, особенно внешние вызовы
И тут начинаются варианты, как это можно пофиксить:
1️⃣ Можно сначала отправить событие в Kafka, а потом сохранить в БД в транзакици
А что если потом транзакция в БД откатится?
В итоге в Kafka улетело OrderCreated, но самого заказа в базе нет. Другие сервисы начали реагировать на событие о заказе, которого не существует.
2️⃣ Сначала сохранить заказ в БД, а событие отправить после коммита
Но если приложение упадёт между коммитом и отправкой в Kafka?
Заказ в базе будет, а события не будет. Другие сервисы не узнают, что заказ создался
❗️Именно эту проблему решает Transactional Outbox Pattern
Идея простая: в одной транзакции с бизнес-данными мы сохраняем не только заказ, но и событие в отдельную таблицу - outbox_events
То есть внутри одной БД-транзакции происходит сразу две записи:
@Transactional
public void createOrder(CreateOrderRequest request) {
Order order = orderRepository.save(new Order(request));
outboxRepository.save(new OutboxEvent(
OrdersEvents.ORDER_CREATED,
order.getId(),
toJson(new OrderCreatedEvent(order))
));
}
Теперь заказ и событие точно сохраняются атомарно. Либо сохранилось и то, и другое. Либо не сохранилось ничего
🤔 Окей, а дальше как?
А уже потом отдельный процесс или задача по расписанию (poller) читает outbox_events и публикует события в Kafka
Service → orders + outbox_events → Poller → Kafka
Это может быть обычный poller, который раз в секунду берёт новые события из таблицы, отправляет их в Kafka и помечает как опубликованные.
Либо можно использовать CDC-подход, например Debezium: он читает изменения из журнала WAL SQL базы и отправляет их дальше в Kafka
PostgreSQL WAL → Debezium → Kafka
Но у Outbox есть важный нюанс: обычно он даёт at-least-once delivery. То есть событие может быть доставлено больше одного раза
Например, poller отправил событие в Kafka, но упал до того, как пометил его как опубликованное. После рестарта он отправит это же событие ещё раз
Поэтому consumer’ы должны быть идемпотентными: уметь спокойно обработать одно и то же событие повторно. Обычно для этого используют eventId и таблицу уже обработанных событий. Писал про идемптоентность тут
❓ На собеседованиях по этой теме часто спрашивают
• зачем нужен Outbox Pattern?
• почему нельзя просто отправить событие в Kafka внутри @Transactional?
• что будет, если БД закоммитилась, а Kafka-send упал?
• что такое outbox-таблица?
• почему consumer должен быть идемпотентными и что будет если НЕ?
💡 Outbox Pattern нужен, когда изменение в БД и публикация события должны быть логически связаны, но физически происходят в разных системах. Мы сохраняем событие рядом с бизнес-данными в рамках одной транзакции и потом доставляем его во внешнюю систему
Накидай огня, если пост зашел 🔥
А в комментах расскажи, какие моменты по Кафке тебе еще не понятны, выберу одну из тем и напишу пост 😎
#хардовая_польза | 4 979 |
| 19 |  Теперь зовите меня вайб дизайнер ⌨️
Вот эти все шаблоны слайдов клод собрал сам, я просто сидел смотрел
Всё, уже можно продавать курс "Как зарабатывать на нейросетях" или пока рано?))) | 4 544 |
| 20 |  +1Круто дизайнить через Claude, не круто дизайнить через Claude Design
Итак, проблема номер один - мне сейчас надо делать кучу презентаций: для видосов на ютуб и новый продукт мне надо +- 500 слайдов
Проблема номер два - я вот совсем не дизайнер:)))
Поэтому когда клод выкатили claude design, я подумал что вот оно спасение ща всё нарисуем 🍷
Нууу... я часов 5 закидывал презы и прочее туда для создания проекта, на выходе получив реально красивые слайды в моей стилистике
Вот только вместе с ними шли кривые диаграммы, поехавший текст и абсолютная невозможность это редачить - промтами жрет кучу токенов, вручную нормально тоже толком это не сделать
Пошел ресерчить че с этим делать дальше, понял что можно связать просто десктопный клод и фигму, чтобы он сам там собирал слайды ⌨️
Снова сидел кормил ему презентации, примеры диаграмм, собирал брендбук и тп
И вот это уже оказалась максимально рабочая штука - сами слайды чуть менее красивые, зато всё легко редачится, диаграммы не поехавшие ну и так далее. Скоро всё увидите
Так что вывод у поста простой - не стоить выдрачивать всё до идеала, когда можно сделать просто рабочую штуку
Поэтому для себя я перефразирую фразу "Лучше сделать херово, чем никак" в "Лучше сделать хорошо, чем идеально"
P.S. "а деньги что делать" пхавхпхвапвахпхвапхв | 4 748 |
