🔧 Как устроена масштабируемая система

Представьте, что вам нужно обрабатывать миллионы запросов и файлов — как это сделать эффективно? Ответ кроется в правильном проектировании архитектуры.

Вот ключевые компоненты:

🔹 DNS — запросы перенаправляются на нужный сервер.

🔹 Балансировка нагрузки — равномерное распределение трафика между серверами для избежания перегрузок.

🔹 Масштабирование — использование распределенных сервисов и кеширования для работы с большими объемами данных.

🔹 Обработка медиа — загрузка и обработка изображений/видео с последующей обработкой метаданных.

🔹 Базы данных — распределение данных и управление запросами для обеспечения высокой доступности.

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

🐸 Библиотека джависта

#буст

🤫 Что действительно важно в Java 21

Ну всё, хватит отдыхать 😁
Обсудим интересные фичи 21 java.

Переход на версию LTS — не просто "модно", а реальная возможность повысить продуктивность проекта. Вот на что стоит обратить внимание:

1️⃣ Виртуальные потоки (Virtual Threads)

При миллионе одинаковых тестовых задач время получается следующее :
— FixedThreadPool : 33 мин.
— CachedThreadPool : 1:26 мин.
— VirtualThreadPerTask : всего 14 секунд

Производительность и масштабируемость на новом уровне.

2️⃣ Улучшенные паттерны и паттерн-свитчи

Record-паттерны позволяют одновременно проверять тип и извлекать поля, свитчи стали мощнее — меньше кода, больше читаемости.

3️⃣ Generational ZGC (Garbage Collector)

Минимальные задержки (sub-миллисекунды) и оптимальное управление памятью, что идеально для latency-чувствительных приложений.

4️⃣ Строковые шаблоны (String Templates)

Новый синтаксис для динамических строк (например, JSON-создание) создает меньше ошибок и улучшает читаемость.

5️⃣ Коллекции с упрощённой навигацией (Sequenced Collections)

Последовательные операции легко доступны: getFirst(), getLast(), reversed() — удобно и логично.

💬 Кто уже работал с виртуальными потоками?

🐸 Библиотека джависта

#буст

🥇 Унификация API-ошибок в Spring Boot

Чёткая схема API помогает наладить диалог между провайдером и клиентом, а единый формат ошибок — избавить потребителей от хаоса в коде и лишних поводов для «боли».

🔹 В Spring Boot по умолчанию структура ошибок выглядит так:

{
"timestamp": "2021-15-08T14:32:17.947+0000",
"status": 500,
"error": "Internal Server Error",
"path": "/test"
}

Такая форма ответа не всегда содержит тип ошибки для обработки на клиенте, а также предоставляет мало контекста для формирования пользовательских сообщений.

🔹 Решение: разработать унифицированную структуру, например:

{
"error": {
"type": "USER_NOT_FOUND",
"message": "User with ID 12345 not found.",
"status": 500,
"path": "/integration/apps",
"timestamp": "2021-15-08T14:32:17.947+0000",
"data": {
"userId": "12345"
}
}
}

🔹 Как внедрить:

▪️ Создаём единое исключение AppException:

public final class AppException extends RuntimeException {
private final ErrorType type;
private Map<String, Object> data;
// конструктор и геттеры...
}
public enum ErrorType {
USER_NOT_FOUND(404), AUTHENTICATION_FAILED(401), …;
private final int status;
// геттеры...
}

▪️ Глобальный обработчик:
Используем @ControllerAdvice с @ExceptionHandler(AppException.class) для перехвата ошибок и возвращения QErrorResponse, содержащего нужную структуру

▪️ Обработка всех остальных ошибок:
Создаём свой ErrorController, заменяющий BasicErrorController, и возвращаем данные в таком же формате QErrorResponse:

@RestController
@RequestMapping("${server.error.path:${error.path:/error}}")
public class RestErrorController extends AbstractErrorController {
// логика формирования QErrorResponse…
}

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

🔹 Почему это важно:

— Унификация ответа облегчает обработку ошибок на клиенте.
— Контекст в data позволяет выдавать более понятные сообщения пользователю.
— Расширяемость дает возможность добавлять новые типы ошибок при сохранении консистентности.

🐸 Библиотека джависта

#буст

🐸 Библиотека джависта

#развлекалово

🏃‍♀️ Новый поток курса — собери своих AI-агентов

7 октября стартует второй поток курса «AI-агенты для DS-специалистов».
За 5 недель вы научитесь собирать агентов, которые уже сейчас будут помогать бизнесу.

В кружке выше Максим Шаланкин, наш преподаватель, рассказывает подробнее — включай, чтобы не пропустить.

👉 Записаться на курс

😮 Топ-вакансий для джавистов за неделю

Senior Java Developer (MAX) — от 300 000 ₽ — удалёнка

Программист Java — от 100 000 до 140 000 ₽ — офис (Москва)

Java-разработчик — 300 000 —‍ 490 000 ₽ — гибрид (Москва)

Java Developer (Клик) — от 400 000 ₽ — гибрид (Москва)

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

💬 Обратная связь

Друзья, давайте сделаем контент лучше вместе. Расскажите, что вам сейчас наиболее интересно в Java?

📌 Возможные направления:

— Многопоточность и конкурентность (best practices, паттерны)
— Работа с БД и ORM (Hibernate, JOOQ, тонкости оптимизации запросов)
— Spring Boot (реальные кейсы, архитектурные решения)
— JVM (память, GC, тюнинг производительности)
— Алгоритмы и структуры данных
— Безопасность и практики secure-coding
— Инструменты: тестирование, CI/CD, мониторинг

👇🏻 Пишите в комментариях, что сейчас изучаете или было бы интересно изучить. Постараемся адаптировать посты под наиболее интересные темы.

🐸 Библиотека джависта

👀 Задача с собеса: Потокобезопасный LRU-кэш с TTL (middle)

Отдохнули и хватит😁
Интересная задачка с реального собеседования:

Компания хочет снизить нагрузку на БД и внешние API. Реализуйте in-memory кэш, который:

— хранит не более N элементов (LRU-политика вытеснения)
— истекает срок действия записей по TTL
— потокобезопасен и работает за O(1) на get/put

▪️ Условия

1. put(k, v) кладёт значение с TTL (единый для экземпляра).
2. get(k) возвращает значение или null, если пары нет или истёк TTL.
3. При переполнении удаляется «наименее недавно использованный» элемент.
4. Решение должно быть неблокирующим по чтению или, как минимум, с короткими критическими секциями.
5. Допустимо ленивое удаление устаревших записей (на чтении/записи).

💡 Ключевые моменты:

— Выбор структуры: LinkedHashMap с accessOrder=true даёт LRU «из коробки».
— TTL: храните expireAt на элемент; чистите лениво и/или периодически.
— Потоки: короткие секции под ReentrantReadWriteLock (или один ReentrantLock) вокруг критичных операций.
— Амортизация O(1): не делайте полных проходов по карте на каждом вызове.

💬 Возможная реализация в комментариях. Пишите также ваши реализация и способы оптимизации.

🐸 Библиотека собеса по Java