Паттерны проектирования систем - шпаргалка

🔸Webhooks и Outbox
Надёжные внешние уведомления.
Когда использовать — интеграции, сторонние колбэки.
Типичные проблемы — статусы оплат, синхронизация CRM.

🔸Blob/Object Storage
Дешёвое хранение больших файлов.
Когда использовать — медиа, бэкапы, экспорты.
Типичные проблемы — загрузки пользователей, data lake.

🔸Оркестратор задач (Airflow/Temporal)
Долгоживущие процессы с состоянием.
Когда использовать — длинные задачи, SLA.
Типичные проблемы — генерация отчётов, обработка видео.

🔸Blue-Green / Canary деплой
Постепенное переключение трафика.
Когда использовать — безопасные релизы, быстрый откат.
Типичные проблемы — деплой API, смена конфигураций.

🔸Feature Flags
Включение/отключение фич на лету.
Когда использовать — эксперименты, переключатели.
Типичные проблемы — A/B тесты, скрытые релизы.

🔸Стратегия миграции схемы
Обратная/прямая совместимость.
Когда использовать — миграция без простоя БД.
Типичные проблемы — expand-migrate-contract.

🔸Распределённые блокировки / выбор лидера
Координация одного активного воркера.
Когда использовать — уникальность cron, шардовое владение.
Типичные проблемы — один консумер, лидер партиции.

🔸Наблюдаемость (логи/метрики/трейсы)
Понимание, что делает система.
Когда использовать — SLO, отладка, планирование.
Типичные проблемы — задержка p99, error budget.

🔸Безопасность: AuthN/AuthZ
Проверка личности и прав доступа.
Когда использовать — мультиарендные продукты, внешние API.
Типичные проблемы — OAuth2/OIDC, RBAC/ABAC.

🔸Мультиарендность (pool/bridge/isolated)
Уровни изоляции данных и ресурсов.
Когда использовать — SaaS с множеством клиентов.
Типичные проблемы — отдельные БД на арендатора vs общая схема.

🔸Edge Compute/функции
Запуск логики ближе к пользователю.
Когда использовать — низкая задержка, лёгкие задачи.
Типичные проблемы — персонализация на краю, A/B тесты.

🔸Rate-Aware DB Patterns
Пакетная, очередная, троттлинг у БД.
Когда использовать — горячие партиции, блокировки.
Типичные проблемы — массовый импорт, ID hotspot.

🔸Стратегии пагинации
Keyset > Offset для больших данных.
Когда использовать — бесконечный скролл, большие таблицы.
Типичные проблемы — пагинация фидов, списки в админке.

👉 Java Portal

Кто до сих пор путается в деревьях, графах и сортировках, вот топчик:

https://visualgo.net/en

Визуалка чисто для мозга, всё анимировано: стек, очередь, DFS, BFS, сортировки, хэш-таблицы.

Как будто смотришь, как думает комп. Залипнуть можно. 😳

Сохрани

👉 Java Portal

Освой планирование в Spring Boot с помощью Cron-задач и начальной задержки.

🔸Cron Job

Планировщик cron запускает задачи в определённое время, используя cron-выражение.

Это самый гибкий способ планировать задачи в Spring Boot — можно запускать их ежедневно, еженедельно, ежемесячно или по любому заданному шаблону.
Пример ниже выполняется каждый день в 9:00 утра по времени IST.

@Scheduled(cron = "0 0 9 * * ?", zone = "Asia/Kolkata")
public void runCron() {
    System.out.println("Daily at 9:00 AM");
}

Формат cron: секунда минута час день месяц деньНедели

Примеры:

0 0 0 * * ? → каждый день в полночь

0 0/15 * * * ? → каждые 15 минут

Используйте cron, когда нужна точность, например для генерации отчётов в конце дня.

🔸Initial Delay

Параметр initialDelay говорит Spring Boot, сколько ждать после запуска приложения перед первым выполнением задачи.

После первого запуска задача будет работать с указанным fixedRate или fixedDelay.

Пример: код ниже ждёт 10 секунд после старта, затем выполняется каждые 5 секунд от начала предыдущего запуска.

@Scheduled(initialDelay = 10000, fixedRate = 5000)
public void runWithDelay() {
    System.out.println("Starts after 10s, then every 5s");
}

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

👉 Java Portal

27 августа встречаемся на DrinkUp от Авито для backend-разработчиков в Нижнем Новгороде. Уже предчувствуем горячие споры… ☄️

В планах в формате дискуссий обсудить:
➡️ как правильно структурировать проекты;
➡️ кому и как проще вкатиться в Go и почему он такой странный;
➡️ как LLM помогает разработчикам.

Остальные темы раскрывать не будем — можете посмотреть их по ссылке! Там же, кстати, и регистрация на ивент.

8 лучших практик при проектировании API

① Понятные названия → единообразные URL и коллекции
② Идемпотентность → безопасные повторы запросов с одинаковым результатом
③ Пагинация → ограничение количества результатов для снижения нагрузки
④ Сортировка и фильтры → возможность фильтровать результаты
⑤ Кросс-ссылки → не злоупотреблять query string
⑥ Ограничение частоты запросов → контроль количества запросов для стабильности
⑦ Версионирование → сохранение обратной совместимости
⑧ Безопасность → защита через API Keys, JWT, OAuth2

👉 Java Portal

Java Logging (SLF4J, Logback) — всё, что нужно знать

1. Логирование → запись событий приложения для отладки и мониторинга
Помогает находить проблемы без запуска отладчика
Пример: запись неудачной попытки входа для целей безопасности

2. SLF4J → простой фасад для логирования в Java
Вы пишете код против API SLF4J, а дальше подключаете любую реализацию логгера
Пример: один и тот же код будет работать с Logback, Log4j или java.util.logging

3. Logback → популярный backend для логирования
Высокая производительность, гибкость, поддержка фильтров и политик ротации
Пример: запись логов в файл с ежедневной ротацией

4. Зачем использовать SLF4J + Logback
- SLF4J → возможность менять backend без переписывания кода
- Logback → функционал продакшен-уровня и высокая производительность

5. Уровни логирования (общие для большинства фреймворков)
- TRACE → подробная внутренняя информация (редко в продакшене)
- DEBUG → отладочная информация (например, значения переменных)
- INFO → общие события высокого уровня (например, «Пользователь успешно зарегистрирован»)
- WARN → неожиданные, но восстанавливаемые ситуации (например, повторный запрос)
- ERROR → критические ошибки, влияющие на функционал

6. Пример настройки

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyService {
    private static final Logger logger = LoggerFactory.getLogger(MyService.class);

    public void processOrder(String orderId) {
        logger.info("Processing order {}", orderId);
        try {
            // бизнес-логика
        } catch (Exception e) {
            logger.error("Error processing order {}", orderId, e);
        }
    }
}

🔸Используйте параметризованное логирование
logger.debug("User {} logged in", userId) → избегайте конкатенации строк

🔸Выбирайте правильный уровень логов — не захламляйте прод debug-сообщениями

🔸Разделяйте логи приложения и фреймворков

🔸Применяйте политику ротации, чтобы не копились огромные файлы

🔸Добавляйте correlation ID для трейсинга запросов между сервисами

Не логируйте чувствительные данные (пароли, токены)

👉 Java Portal

Чувак сделал несколько Live Templates для intellijidea, которыми часто пользуется

👉 https://github.com/sivaprasadreddy/intellij-live-templates

С каждой новой версией IntelliJ IDEA часть этих штук появляется прямо из коробки

Например, шаблоны для логов и создания Spring-компонентов уже доступны OOTB

На примере небольшой демо, как можно быстро создавать логгер и Spring-компоненты прямо в intellijidea

👉 Java Portal

Автоматический toString() в Record

record сравнительно новая фича в Java, которая позволяет описывать сущности без явного объявления полей и написания геттеров/сеттеров.

Пример:

record User(String name, int age, String city) { }

Если писать это же через класс, получится больше кода:

class User {
    public String name;
    public int age;
    public String city;

    public User(String name, int age, String city) {
        this.name = name;
        this.age = age;
        this.city = city;
    }
}

И в том и в другом случае мы получаем объект для хранения данных:

new User("Nick", 20, "New York");

Но есть отличие

У record метод toString() генерируется автоматически и выводит имена и значения всех полей в удобном формате.

В обычном классе дефолтный toString() возвращает имя класса и хэш объекта.

Пример:

record User(String name, int age, String city) { }

class SecondUser {
    public String name;
    public int age;
    public String city;

    public SecondUser(String name, int age, String city) {
        this.name = name;
        this.age = age;
        this.city = city;
    }
}

public static void main(String[] args) throws Exception {
    User firstUser = new User("Nick", 20, "New York");
    SecondUser secondUser = new SecondUser("Charley", 25, "New York");

    System.out.println(firstUser);
    System.out.println(secondUser);
}

Вывод:

User[name=Nick, age=20, city=New York]
org.example.SecondUser@68de145

То есть у record toString() сразу готов, а для обычного класса придётся переопределять вручную.

👉 Java Portal

🤢🤢🤢Проводим самый БОЛЬШОЙ розыгрыш этого лета сразу на 🤢🤢🤢🤢🤢🤢🤢 рублей

РАЗЫГРЫВАЕМ iPhone 16 Pro Max, Macbook Air M4, AirPods Pro и кучу других призов — с вас всего лишь подписка.

Для участия нужно:
🤢Быть подписанным на Техночат и Сёрч
🤢Нажать «Участвую!» под этим постом

Итоги подведём 8 сентября в 18:00 случайным образом при помощи бота. Доставка для победителя бесплатная. Всем удачи!

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

Open-source: https://github.com/stan-smith/FossFLOW

👉 Java Portal

Java Off-Heap Memory с DirectByteBuffer

Большинство Java-разработчиков работают только с объектами в куче JVM, управляемой Garbage Collector.

Но в системах с высокими требованиями к производительности — базах данных, игровых движках или messaging-системах — Java может использовать off-heap memory (память вне кучи JVM) через DirectByteBuffer

Преимущества

- снижение пауз GC
- ускорение I/O операций
- возможность работать с большими наборами данных без раздувания кучи

👉 Java Portal