Ограничение частоты запросов в Spring Boot с помощью Bucket4j

Реализация rate limiting в REST API на Spring Boot с использованием Bucket4j для контроля частоты запросов на пользователя, что повышает масштабируемость API. Подходит для предотвращения злоупотреблений в продакшн-системах

• Импортируются классы из Bucket4j, Spring и Java SDK.
• Создаётся REST-контроллер с маппингом /api
• Для каждого пользователя создаётся бакет с лимитом 5 запросов в минуту. Если бакет позволяет — запрос проходит. Если нет — возвращается 429 статус.
• Заглушка для HttpServletResponse, нужна чтобы код можно было запускать без настоящего HTTP-сервера.

👉 Java Portal

Все ключевые слова Java в одном месте

Java содержит 53 зарезервированных ключевых слова, которые нельзя использовать как имена переменных, методов или классов — каждое из них выполняет определённую роль в языке.

Независимо от того, только ли ты начинаешь изучать Java или готовишься к собеседованию — знание этих ключевых слов обязательно

👉 Java Portal

Прокачай производительность своего Java-приложения с помощью мощного кэширования.

Узнай, как интегрировать Spring Boot, Redis и Docker в этом практическом гайде.

Читать сейчас: тык 😈

👉 Java Portal

Sealed-классы и интерфейсы в Java

Они позволяют явно контролировать, какие классы могут расширять или реализовывать тип — делая иерархии безопаснее, легче в сопровождении и идеально подходящими для исчерпывающего pattern matching'а

Начиная с Java 17, были введены sealed-классы и sealed-интерфейсы как способ ограничить и контролировать иерархию наследования.

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

🔹Используй модификатор sealed и ключевое слово permits, чтобы явно указать разрешённые подклассы или реализации.
🔹Все разрешённые подтипы должны находиться в одном модуле или пакете и обязаны быть помечены как final, sealed или non-sealed

Зачем использовать sealed-классы и интерфейсы?

👉 Более строгая инкапсуляция и контроль над публичным API
👉 Безопасный и предсказуемый код (отлично подходит для pattern matching в switch)
👉 Защита от нежелательного наследования или реализации

👉 Java Portal

Давайте разберёмся с Git Merge и Rebase

Git предоставляет два мощных инструмента для интеграции изменений из одной ветки (часто feature-ветки) в другую (обычно main):

Merge и Rebase

Оба инструмента решают одну задачу — объединение кода, но делают это по-разному.

✔️ Git Merge

Merge создаёт новый коммит, который фиксирует объединение двух веток.
В истории это видно как слияние двух независимых линий разработки в одной точке.

Шаги:

1. Переключись на целевую ветку (обычно main)
2. Выполни git merge <feature> — укажи имя исходной ветки

Результаты:

🔸Создаётся новый merge-коммит в целевой ветке с ссылками на родительские коммиты
🔸История целевой ветки становится разветвлённой, отражая все слияния
🔸Это более безопасный вариант для командной работы — история изменений сохраняется

✔️ Git Rebase

Rebase переписывает историю ветки (обычно feature-ветки), как будто коммиты были сделаны поверх другой ветки (например, main).

Получается более линейная история без merge-коммитов.

Шаги:

1. Переключись на ветку, которую хочешь ребейзнуть (например, feature)
2. Выполни git rebase <main>

Результаты:

🔸Коммиты из feature будут повторно применены на вершину main, создаются новые коммиты с теми же изменениями
🔸Целевая ветка (main) при этом не изменяется
🔸История feature-ветки становится линейной, но её история будет переписана

Примечания:

После успешного rebase, финальное merge в main часто выполняется как fast-forward, т.к. история выглядит непрерывной

Rebase изменяет ветку, на которой ты находишься, а не целевую ветку

Итог:

merge сохраняет историю как есть → хорошо для командной работы

rebase делает историю аккуратной → хорошо для чистоты, но требует осторожности

👉 Java Portal

Добавление логирования HTTP-запросов в Spring Boot API

⏩Читать подробнее

👉 Java Portal | #cтатья

Проектирование Backend-системы. Система уведомлений

Цель —> Разработать систему для доставки уведомлений пользователям через:

➣ Встроенные уведомления
➣ Push-уведомления (мобильные/веб)
➣ Email

С поддержкой:

✓Масштабируемости (миллионы пользователей)
✓Настраиваемых пользовательских предпочтений
✓Надежности, повторных попыток и дедупликации
✓Реального времени и пакетных оповещений

Пошаговый сквозной процесс

Шаг 1: Срабатывание события

✓ Приложение инициирует событие:

➣ Например, пользователь A лайкнул ваш пост
➣ Отправляется запрос POST на API /notify:

{
  "event_type": "like",
  "actor": "UserA",
  "receiver": "UserB",
  "object": "Post123"
}

Шаг 2: Добавление в очередь уведомлений

➣ API валидирует данные и помещает сообщение в очередь уведомлений (Kafka/RabbitMQ)

Шаг 3: Обработка воркером

✓ Воркер извлекает сообщение из очереди:

➣ Получает полную информацию о событии
➣ Обращается к сервису предпочтений:

- Подписан ли UserB на уведомления типа "like"?

- Хочет email или только in-app?

✓ Создает payload уведомления, например:

✓ "UserA лайкнул ваш пост 'How to scale systems'"

Шаг 4: Рассылка по каналам

✓ На основе предпочтений воркер запускает соответствующие каналы:

➣ In-App Writer → сохраняет в БД (для отображения иконки колокольчика)
➣ Push-сервис → отправляет push (мобильный/веб) через FCM/APNs
➣ Email-сервис → ставит email в очередь (через SES/SendGrid)

Шаг 5: Отправка и повторные попытки

✓ Сервисы каналов:

➣ Декуплированы для изоляции отказов
➣ Повторяют попытки при сбоях (3–5 раз с экспоненциальной задержкой)
➣ Логируют статус (отправлено, ошибка, пропущено)

Шаг 6: Отображение in-app уведомлений

✓ UI вызывает /notifications?user=UserB
✓ Возвращаются N последних уведомлений из БД:

[
  { "text": "UserA лайкнул ваш пост", "read": false, ... }
]

Функции надежности

✓ Гарантированная доставка хотя бы один раз с идемпотентной записью
✓ Повторные попытки с экспоненциальной задержкой
✓ DLQ (Dead Letter Queue) для сообщений с ошибками
✓ Метрики: успех/неудача на сообщение
✓ Алерты при переполнении очереди или всплесках ошибок

👉 Java Portal

Наблюдаемость Java-бэкенда с помощью OpenTelemetry

⏩Читать подробнее

👉 Java Portal | #cтатья