Очень частый сценарий для собеседований по Java/бэкенду, который игнорировать нельзя.

Нужно ли защищать API?

Сценарий = ваш endpoint для логина может вызываться не более 10 раз в минуту для одного пользователя.

→ Простейший подход — Fixed Window Counter (счётчик фиксированного окна) = считаем запросы с 10:01 до 10:02, потом сбрасываем счётчик.

Проблема? Пользователь может сделать 10 запросов в 10:01:59 и ещё 10 в 10:02:01. Итого 20 запросов за 2 секунды 🤯

Для более надёжного решения используют Sliding Window для плавного ограничения или Token Bucket, чтобы корректно обрабатывать всплески.

→ Sliding Window
Избегает проблемы резких всплесков на границе окна. Вместо фиксированной минуты (например, 10:01) считает запросы за последние 60 секунд от момента запроса. Дает более плавное и точное ограничение скорости.

→ Token Bucket
Отлично подходит для корректной обработки всплесков. Представьте ведро, которое постепенно наполняется «токенами» (например, 1 токен в секунду, ведро для одного пользователя/IP/endpoint). Каждый API-запрос «съедает» один токен. Если токенов нет — запрос отклоняется. Так контролируется средняя скорость, но при этом пользователи могут накопить несколько токенов для небольшого всплеска.

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

👉 Java Portal

«99% аптайма достаточно».

Эту сказку слишком многие команды рассказывают сами себе.

А теперь математика:

• 99% аптайма —> примерно 7 часов простоя в месяц
• 99.9% —> около 40 минут
• 99.99% —> около 4 минут

Семь часов вроде не звучат страшно, но на масштабе это убивает доверие, срывает SLA и сжигает деньги.

И даунтайм не всегда выглядит как большой и громкий инцидент.

Он подкрадывается через такие вещи, как:

• платежка, которая теряет запросы без ретраев
• битый конфиг кэша, из-за которого трафик встаёт
• сервис, который тихо отваливается для части пользователей

Поэтому надёжность это не погоня за «100%». Это про системы, которые умеют гнуться, но не ломаться.
Ретраи. Circuit breakers. Фолбэки с сохранением работоспособности.
И правильные метрики — error budgets, а не красивые проценты для отчёта.

Потому что пользователю плевать на твой аптайм в дэшборде.
Ему важно, чтобы продукт работал, когда это реально нужно.

Так что когда кто-то снова скажет «99% это нормально», спроси его
Нормально для графика или нормально для клиента?

👉 Java Portal

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

Паттерн SAGA работает как умный тревел-агент для микросервисов. Он управляет последовательностью операций —> сначала бронируем перелёт, потом отель.

Если один шаг падает, автоматически запускаются компенсирующие действия, которые откатывают предыдущие шаги —> например отмена перелёта.

Это гарантирует, что система не окажется в неконсистентном состоянии. Такой подход реально выручает, когда нужно работать с транзакциями в распределённых Java-сервисах.

Как это работает:

Успешный путь - bookFlight() → bookHotel() → rentCar() и можно ехать отдыхать.

При провале, если bookHotel() падает, в catch запускается cancelFlight() и первый шаг откатывается.
В итоге ты не остаёшься с перелётом в никуда, а система сохраняет консистентность.

👉 Java Portal

Шпаргалка по Java

👉 Java Portal

В Java-приложениях одна небольшая настройка может улучшить производительность в 50 раз.

@Transactional  
public List<Order> getRecentOrders() {  
    return orderRepository.findRecent();  
}  

Видите здесь что-нибудь странное?

Аннотация @Transactional на методе, который просто делает read/GET вызов.

Хуже всего то, что по умолчанию @Transactional работает в режиме read-write, то есть:

- лишние блокировки ресурсов;
- база вынуждена обрабатывать транзакцию даже для простого SELECT.

Что можно сделать:

@Transactional(readOnly = true)

Это позволит:

Пропустить ненужные flush-операции в Hibernate.
Оптимизировать работу транзакций для SELECT-запросов.
Уменьшить оверхед от прокси и избежать лишних блокировок.

Правила, которые стоит помнить:

Не вешайте @Transactional везде подряд только ради «красоты».
Используйте @Transactional(readOnly = true) для запросов.
Убирайте @Transactional, если методу вообще не нужна транзакция.
Регулярно профилируйте приложение — мелкие ошибки выливаются в огромные потери производительности.

👉 Java Portal

⌨️ Как вырасти до Мидла или Синьора в два раза быстрее?

👨‍💻Просто хорошо работать работу не достаточно. Ты делаешь то, что нужно компании, а не то, что повысит твой грейд

Лучший способ вырасти — это персональный план развития от Senior-инженера из БигТеха.

Вот как все работает:
1️⃣ Мок-интервью 1-на-1: Час реалистичного собеса с Senior-инженером из Иннотеха, Сбера или другого бигтеха
2️⃣ Честный фидбек: созвонимся и расскажем твои точки роста, оценим грейд и потенциальный уровень зарплаты
3️⃣Персональный план развития: не просто «учите алгосы», а роадмап с конкретными темами, который приведет тебя к желаемому грейду или офферу. Пример плана развития прикрепили к сообщению

Мы в ШОРТКАТ провели уже почти 1000 таких мок-интервью и получили оценку 4.9/5, поэтому знаем о чем говорим.

📈 Да, и все это за 900 рублей. Почему так дешево?
Мы хотим, чтобы у каждого была возможность проверить в деле наш сервис, а потом уже доверить нам свое развитие.

Переходи в нашего бота и забирай свой мок за 900 рублей → @shortcut_sh_bot

Реклама.
О рекламодателе.

14 алгоритмов сортировки в одной минуте

👉 Java Portal

Недавно на собеседовании кандидата спросили о четырёх основных функциональных интерфейсах Java 8. Когда его попросили объяснить каждый из них, он растерялся.

Вот эти 4 основных функциональных интерфейса:

I. Predicate<T>
Проверяет, удовлетворяет ли входное значение условию, возвращая true или false.
Как я запоминаю: как фейс-контроллер в клубе, который проверяет, есть ли ты в списке гостей, прежде чем пустить внутрь.

II. Function<T, R>
Принимает один аргумент и возвращает один результат, трансформируя данные.
Как я запоминаю: торговый автомат, который принимает монету (вход) и выдает газировку (выход).

III. Supplier<T>
Предоставляет результат без необходимости передавать аргументы, как фабричный метод.
Как я запоминаю: волшебная шляпа, из которой по запросу достается кролик, без предварительных условий.

IV. Consumer<T>
Принимает входное значение и выполняет над ним действие, но ничего не возвращает.
Как я запоминаю: мусорное ведро, которое принимает твой мусор (вход) и просто утилизирует его, без всякой «квитанции» на выходе.

На скрине пример, который использует все эти 4 интерфейса.

👉 Java Portal

Парсинг на Java. От основ до парсинга Яндекс Карт

Сегодня разбираем основы парсинга на Java с практическим примером на Яндекс Карт.

В статье рассматривается, что такое HTTP, как работают методы запросов, как использовать HttpClient в Java 11+ для отправки GET и POST-запросов, как обрабатывать HTTP-ответы и извлекать данные. Всё это показано на примере парсинга данных с внешнего сервера через Яндекс Карты, чтобы дать полное представление о работе с сетевыми запросами в Java.

👉 Java Portal

В продакшн-коде использование длинных цепочек if-else обходится слишком дорого -> лишний else может привести к падению приложения. Понимание того, чем их заменить, отличает джуна от сеньора.

if (paymentType.equals("creditcard")) {
    processCreditCard(payment);
} else if (paymentType.equals("upi")) {
    processUpi(payment);
} else if (paymentType.equals("crypto")) {
    processCrypto(payment);
}

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

Когда логика усложняется, код становится трудным для тестирования, расширения и чтения.

Что делают опытные Java-разработчики? Они часто заменяют такие конструкции паттерном Strategy.

Strategy можно сравнить с выбором способа добраться до аэропорта. Вместо одной гигантской функции с if-else на тему «поехать на автобусе», «взять такси» или «сесть на поезд» ты создаёшь отдельную «стратегию» под каждый вариант. Основной код просто выбирает нужную стратегию и говорит: «Поехали».

Вместо бесконечных блоков else if ты:
→ Определяешь интерфейс стратегии (PaymentStrategy).
→ Создаёшь отдельные реализации под каждый случай (CreditCardPayment, UpiPayment).
→ Используешь Map для выбора нужной стратегии во время выполнения:

strategyMap.get(type).processPayment(payment);

Готово. Теперь можно добавлять новую логику, не трогая старый код. Чисто, масштабируемо и поддерживаемо.

👉 Java Portal

Представлен бесплатный онлайн-плейграунд для SQL — RunSQL. 🪿

Сервис позволяет создавать таблицы, писать запросы и делиться результатами с командой. Поддерживаются MySQL, PostgreSQL и SQL Server.

Работает прямо из браузера, ничего устанавливать не нужно: http://runsql.com/r

👉 Java Portal

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

Главное, что должен знать каждый Java-разработчик:

serialVersionUID – если не объявлен, JVM сгенерирует свой. При изменении класса старые объекты перестают десериализоваться. Всегда объявляйте явно.

transient-поля – помечайте чувствительные данные (например, пароли) как transient, чтобы они не записывались на диск или в логи.

Возможны атаки через десериализацию. Никогда не десериализуйте ненадёжный ввод.

👉 Java Portal

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

Ниже три мощные альтернативы HashMap и ситуации, когда стоит их использовать.

WeakHashMap: Самоочищающийся кэш

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

WeakHashMap хранит ключи через слабые ссылки. Если на объект-ключ больше нет сильных ссылок, GC может удалить его, и запись в мапе исчезнет автоматически.

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

IdentityHashMap: Когда объекты "равны", но не одинаковы

HashMap проверяет ключи через метод .equals(). Если у вас два объекта с одинаковыми данными, но это разные экземпляры (например, два Person с одинаковым именем, но разными записями), то HashMap перезапишет значение.

IdentityHashMap сравнивает ключи только по ссылке (==), игнорируя .equals(). Разные объекты всегда будут разными ключами, даже если у них одинаковые данные.

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

EnumMap: Оптимизированный вариант для enum-ключей

Использовать enum как ключ в HashMap неэффективно. Нужно считать хэши, обрабатывать коллизии, хотя набор ключей фиксирован на этапе компиляции.

EnumMap специально создан для enum-ключей. Внутри он работает через массив, используя ordinal() значения enum в качестве индекса. Это даёт настоящие O(1)-операции и экономит память.
Используется всегда, если ключи берутся из одного enum.

Быстрый гайд по выбору:

- Нужно автоочищение кэша → WeakHashMap
- Нужна идентичность объектов (==) → IdentityHashMap
- Ключи из enum → EnumMap
- Всё остальное → HashMap по умолчанию

👉 Java Portal

👩‍💻 Всем программистам посвящается!

Вот 17 авторских обучающих IT каналов по самым востребованным областям программирования:

Выбирай своё направление:

👩‍💻 Java — t.me/java_ready
🤔 InfoSec & Хакинг — t.me/hacking_ready
🖥 SQL & Базы Данных — t.me/sql_ready
👩‍💻 Python — t.me/python_ready
🤖 Нейросети — t.me/neuro_ready
👩‍💻 Linux — t.me/linux_ready
🖼️ DevOps — t.me/devops_ready
📖 IT Книги — t.me/books_ready
👩‍💻 C/C++ — https://t.me/cpp_ready
👩‍💻 C# & Unity — t.me/csharp_ready
👩‍💻 Frontend — t.me/frontend_ready
📱 JavaScript — t.me/javascript_ready
👩‍💻 Backend — t.me/backend_ready
📱 GitHub & Git — t.me/github_ready
👩‍💻 Весь IT — t.me/it_ready
👩‍💻 Bash & Shell — t.me/bash_ready
🖥 Design — t.me/design_ready

📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!

Google увеличил функционал Agent Development Kit для Java, внедрив поддержку LangChain4j. Теперь Java-инженеры способны подключать модели OpenAI, Anthropic, Mistral и прочие, разрабатывая многоагентные решения с более гибким контролем и усовершенствованной логикой.

Подробности: тык

👉 Java Portal