Всем привет! Пока, так скозать, горячо (было в коментах) 😂 решила вкратце рассказать про второй известный паттерн из категории resiliency - Rate Limiter.
Кто уже знает этот паттерн - вы лучшие 🤩 кто не знает, щас узнаете)))

Цель паттерна ограничивать количество запросов в единицу времени.
Реализация состоит в том, что задаются определённые значения, сколько запросов и за какое время хочет/может обрабатывать сервис, все запросы сверх этих значений отбрасываются. То есть мы контролируем throughput. Клиент при этом может повторить эти запросы позже, либо взять из кэша предыдущее значение, up to you.
Полезен, как один из инструментов предотвратить DDoS, снять нагрузку если сервис не вывозит и для предотвращения каскадных сбоев.

Мы у себя реализовывали этот паттерн немного нестандартно, когда хотели защитить внешнюю систему от своей пиковой нагрузки.
У нас тогда был большой RPS, а внешняя система могла обрабатывать гораздо меньше.
Пренебречь результатом мы могли, а положить чужой сервис не хотели.
Для cloud native парней (и девчонок) 😏 скажу, что мы реализовали этот паттерн и на nginx’е и в коде с помощью Resilience4j, на всякий случай)
Почему внешняя система не реализовала на своей стороне? Ну потому, это легаси 🤪

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

Расскажите, знаете этот паттерн? Приходилось ли реализовывать на практике?

Оказывается уже есть даты Joker 2023!
В чатике JUG писали, что офлайн будет проходить в Питере
Планируете ехать?
Я да 🤩

Только что проходила мок-интервью с HR для обучающего курса IT- рекрутёров)

Удивительно, но за свою карьеру я не проходила ни одного собеседования с рекрутёрами, сразу техническое собеседование и погнали работать 😅
Было интересно, новый опыт и волнительно, такой мини-стендап имени меня.

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

Были и сложные вопросы, например почему ушла с прошлого места и что будет если моя компания начнёт перебивать новый оффер. Я об этом никогда даже не думала 🤣

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

Короче мне понравилось 😍

Всем привет! Один подписчик подсказал идею написать про Backpressure, я решила и правда, тема классная)

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

Этим термином называют
1) само явление, когда источник информации генерит её быстрее, чем получатель может её принять и обработать
2) механизмы сглаживания и уменьшения этого явления
2.1) в доке реактора написано, что это возможность консюмера сообщить продюсеру, что ему плохо)

Пример: если у меня есть два сервиса и один из них отправляет 20 rps, а второй может принимать и обрабатывать только 10, то будет создаваться дефицит обработки 10 остальных запросов в секунду.
В таком случае рано или поздно второй сервис накопит очередь на обработку и упадёт с OOM, либо не будет обрабатывать эти запросы вообще.

Есть несколько стратегий решения этой проблемы:
• решить на стороне продюсера 😅 (изян)
• копить буфер из сообщений на обработку
• отбрасывать сообщения

Первый вариант самый предпочтительный, поскольку в таком случае не нужно выделять дополнительную память на буфер или дропать сообщения на консюмере.

У нас на практике возникала проблема с backpressure дважды.
Один раз, когда на реактивном стеке мы использовали Scheduler.elastic() и смотрели как сервис падает с OOM 🤪 Сейчас elastic уже задепрекейтили))
Второй раз, когда мы читали из кафки гигантское количество сообщений и делали update в постгрес. Там быстренько разрастался WAL, и на репликах тоже 😨
Решить это до конца мы так и не смогли, крутили и постгрес и консюмера, чтобы медленнее читал. Коллеги поправят, если я что-то ещё забыла)

А у вас была проблема с backpressure? Как решали?

Ребята, я состою в сообществе @ityoutubers_com, хоть и не ютубер 😅
и у нас появилась шаренная папка с нашими IT-каналами 😏🔥
https://t.me/addlist/OSGJfcXF_chhOWIy

Всем привет)
Канал быстро вырос и я очень хочу знать кто вы 🤩

непростительно мало мемов у меня в канале, буду исправлять)

Кто блин эти 10 человек, которые проголосовали на первом опросе и не проголосовали на втором? 🤣🤣🤣

Про собеседования

Всем привет)
Я и мои коллеги достаточно часто проводим собеседования на java разраба, поэтому сегодня, так скозать, о наболевшем))))
Собеседование у нас проходит в несколько этапов, расскажу про техническую часть. Для неё мы придумали список вопросов и разбили их по категориям, чтобы тщательно и побыстрее 😅 оценить кандидата.

Ищем middle+/ senior, поэтому нам важно, чтобы человек мог пояснить за микросервисы и монолиты, всякие паттерны и солиды. Что когда использовать, зачем камунда 🤣
Если в резюме CQRS и Event Sourcing, спросим)
Очень интересно слушать про текущий проект, понимает ли кандидат, как там всё устроено и почему, бывает что нет. 🫠

По инфраструктуре и бд спрашиваем про Kafka и Postgres, это для нас самое важное, т.к. их мы трогаем каждый день. K8s тоже хочется чтобы знали.
Внезапно, мало кто знает, как работает кафка, ребалансировки, оффсеты и т.д., всякие забавные ответы бывают на собесах 🤪

По тестированию обычно спрашиваем про юниты, интегры, тестконтейнеры, etc. Если кандидат делал нагрузочное и тем более на гатлинге, то это ваще мой любимый кандидат сразу 🤩 (пока таких не было 😭)

Фреймворки - про Spring и вокруг него, про хибу и jdbc.
Если в резюме есть реактивщина, то спросим и не дай бог кандидат неверно ответит 🤣

Обязательно показываем код и тут начинается самое интересное, топ кандидаты по предыдущим вопросам могут полностью завалить код и наоборот)

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

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

Один раз у нас был кандидат, который не мог ответить по технологиям из резюме, и сказал что просто туда всё скопировал из вакансии)

Расскажите, как проводите собесы) Что спрашиваете?
Алгоритмы спрашиваете? 🤪

Что вас спрашивали на лучшем собесе в вашей жизни? 🤩

ну и по мотивам поста 🤪

Сегодня весь день ковырялась с Hibernate 😅
На прошлом месте работы у меня его не было, пользовалась Jdbc, а потом и R2dbc и бед не знала))
А сейчас у нас везде Hibernate, приходится изучать, а он мне не нравится)
Я всегда думала хиба, да и JPA в целом, это как из пушки по воробьям, слишком громоздкая штука и эти кэши сомнительные, какие-то контексты. Персистится чёт там всё само, непредсказуемо, неочевидно.

Многие хвалят Hibernate за сокращение количества кода. Блин, ребята, спрингдатовский CrudRepository + Jdbc то же самое)))) (ну почти 😅)
Тем более если у вас, как у меня, в куче микросервисов 1-3 таблицы без связей.

На собесе нам кто-то говорил что если мало таблиц, нет связей, простая схема БД — надо взять Hibernate, объясните плиз зачем???)) Мы тогда так и не поняли.

Кучу аннотаций сегодня пришлось изучать и я нашла классную статью, которая очень понятно объясняет про orphanRemoval, балдёжь)

Короче я решила изучить кэширование в Hibernate, чтобы не только хейтить его, но ещё и умничать про кэши 😂
Расскажу вам скоро про них 😌

Всем привет!
Мы тут с коллегами решили начать использовать layered jar. Может и вам пригодится)
Эта штука появилась в Spring Boot 2.3.0 (май 2020), то есть достаточно давно, но я лично узнала о ней только сейчас 😂
Суть в том, что создаётся jar, содержимое которого разделено на слои, в зависимости от того, как часто это содержимое будет меняться.
Это аналогия докер образов, собственно для большей эффективности в докере и предназначено) Ускоряет создание образа и всё такое))

Можно оставить слоистость по-умолчанию (snapshot и не snapshot зависимости + приложение), а можно настроить более сложные слои. Мы у себя дополнительно создали слой с нашими внутренними зависимостями, которые меняются часто. Ну вы это увидите в любых туториалах в инете 🤣
Ускорения запуска приложения замечено не было)))))

После сборки мы теперь извлекаем слои:
java -Djarmode=layertools -jar app.jar extract

И в Dockerfile у нас они все копируются:
COPY ./build/layers/dependencies/ /app
COPY ./build/layers/spring-boot-loader/ /app
COPY ./build/layers/snapshot-dependencies/ /app
COPY ./build/layers/application/ /app
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

Всем привет!
Вот что я вам сегодня скажу (то что вы и так знаете) — нужно ставить свои сервисы на мониторинг как можно раньше, это очень важно! 🤓

Предыстория (любимый начальник, прошу не читай 😅)
Я на той неделе выкатила свою доработку в прод и только вчера узнала, что у определенной части пользователей при определённых кривых данных перестала работать одна фича.
Давайте опустим вопросы про тестирование, речь не об этом)

Как бы я могла узнать об этом раньше? Если бы мониторила эту фичу)

Очевидно, что мониторинг, это не новость, но почему-то часто на него забивают. Например, когда я пришла на текущий проект, тут было очень мало чего на мониторинге, хотя проект делали не джуны.
Даже на собеседованиях иногда разработчики не знают про графану, либо «у нас маленькая нагрузка», «просто посмотрим логи», «у нас MVP», «руки не дошли» 😒
Блин, это как с тестами, может лучше сначала мониторинг сделать, а потом уже писать функционал 🤣

В общем - настраивайте мониторинг с алертами в тележку и спите спокойно 😌

А еще надо приделывать к логам ошибок какие то мотивационные цитатки, или гороскоп, или анегдот...о, предсказание как из печенек
"Расслабся и пусть весь мир подождет"
"Это не самая лучшая работа в мире"
....

ой не могу 🤣🤣🤣

Кстати про гороскоп
Не благодарите 🤪

https://deployhoroscope.ru