Задумывался, как работают ActiveMQ и RabbitMQ?

В основе у них producer/consumer паттерн.

Как его реализовать?

Это базовая схема обмена данными между несколькими потоками. Поток-продюсер отправляет объекты на условную обработку, а потоки-консьюмеры асинхронно их получают и обрабатывают.

Общий вид решения такой:

продюсер кладет объекты в специальную коллекцию, буфер. Когда консьюмер освобождается, он запрашивает из буфера один объект. Если буфер пустой, консьюмер блокируется и ждёт; если буфер переполнен, ждёт продюсер.

Реализовать этот паттерн можно по-разному.

Самый правильный способ для продакшена: брать готовую реализацию из стандартной библиотеки, например BlockingQueue.

На собеседованиях обычно просят написать реализацию с нуля. На картинке показан один из вариантов.

Модификатор synchronized гарантирует, что в один момент времени выполняется только один из методов и только одним потоком. Этого достаточно для корректной работы, пока буфер не пуст и не переполнен. Когда буфер пустой или полный, управление явно передаётся продюсеру или консьюмеру соответственно через notify() и wait().

👉 Java Portal

Почему твой бэкенд начинает тупить на 10k юзеров, хотя на 100 всё летало

Обычно причина одна из этих:

1️⃣N+1 запросы
→ один запрос незаметно триггерит сотню походов в БД

2️⃣Нет индексов
→ на каждом поиске полный проход по таблице

3️⃣Тяжелая работа синхронно
→ письма, обработка картинок прямо внутри request cycle

4️⃣Нет стратегии кеширования
→ один и тот же запрос в БД выполняется 1000 раз

5️⃣Единая точка отказа
→ один инстанс БД тащит на себе вообще всё

Приложение не стало внезапно медленным.
Оно просто доросло до момента, когда плохие решения стали заметны.

👉 Java Portal

Совет по Java: Stream.toArray(Type[]::new) это аккуратный и типобезопасный способ получить массив из стрима.

Избавляет от Object[] и ручных кастов.

👉 Java Portal