Я побывал по обе стороны собеседований по system design.

Ниже темы, которые нужно изучить, чтобы действительно хорошо в этом разбираться:

1. [Сервер]

2. [Задержка и пропускная способность]

3. [Масштабирование и его виды]
– Вертикальное и горизонтальное масштабирование

4. [Автомасштабирование]

5. [Прикидочные расчеты]

6. [Теорема CAP]

7. [Масштабирование базы данных]
– Индексы
– Партиционирование
– Архитектура master-slave
– Multi-master
– Шардирование базы данных
– Недостатки шардирования

8. [SQL и NoSQL базы данных и когда что использовать]

9. [База данных]
– SQL-база данных
– NoSQL-база данных
– Масштабирование в NoSQL и SQL
– Когда какую базу использовать?

10. [Микросервисы]
– Монолит vs микросервисы
– Зачем вообще разбивать приложение на микросервисы?
– Когда использовать микросервисы?
– Как клиенты делают запросы в микросервисной архитектуре?

11. [Глубокое погружение в load balancer]
– Зачем нужен load balancer?
– Алгоритмы load balancing

12. [Кеширование]
– Плюсы кеширования
– Типы кешей
– Redis

13. [Blob Storage]
– Что такое blob и зачем нужно blob storage?
– AWS S3

14. [CDN, Content Delivery Network]
– Как работает CDN?

15. [Message Broker]
– Асинхронное программирование
– Зачем ставить message broker между сервисами?
– Очередь сообщений
– Поток сообщений
– Когда использовать message broker

16. [Глубокое погружение в Apache Kafka]
– Когда использовать Kafka
– Внутреннее устройство Kafka

17. [Pub/sub в реальном времени]

18. [Event-Driven Architecture]
– Зачем использовать EDA?
– Простое уведомление о событии
– Передача состояния через событие

19. [Распределенные системы]

20. [Самовосстанавливающаяся система с election лидера]

21. [Глубокое погружение в consistency]
– Строгая согласованность
– Когда выбирать strong consistency
– Eventual consistency
– Когда выбирать eventual consistency
– Способы добиться strong consistency
– Способы добиться eventual consistency

22. [Consistent hashing]

23. [Избыточность данных и восстановление данных]
– Зачем делать базы данных избыточными?
– Разные способы резервного копирования
– Непрерывная избыточность

24. [Прокси]
– Forward proxy vs reverse proxy

👉 Java Portal

Совет по Spring Boot: ускорить приложение можно с помощью @EnableCaching и @Cacheable.

🟢Позволяет избежать повторных вызовов к БД и API
🟢 Снижает задержки
🟢 По умолчанию Spring использует in-memory map, но в проде можно подключить внешний провайдер кеша

👉 Java Portal

API Gateway, если по-человечески:

Клиент не должен ходить в 6 разных сервисов.
Он должен ходить в одну точку.

Gateway стоит перед всей системой и берёт на себя:

- маршрутизацию входящих запросов в нужный сервис
- валидацию токенов, например JWT и OAuth, ещё до того, как запрос вообще дойдёт до сервисов
- rate limiting, чтобы API не абьюзили
- логирование, чтобы наблюдаемость была в одном месте
- балансировку нагрузки между инстансами сервисов

Без gateway каждый сервис заново городит у себя аутентификацию, логирование и rate limiting.
С gateway всё это решается один раз, централизованно.

Вот и вся суть: одна точка входа и единый слой контроля.

👉 Java Portal

Не используйте ELSE 0 вместе с COUNT и CASE

Использование ELSE 0 - очень частая ошибка у новичков, когда они комбинируют функцию COUNT с выражением CASE. Обычно это происходит из-за непонимания того, как именно COUNT работает при применении к столбцу.

Когда используется COUNT(column), функция считает все значения, которые не равны NULL, включая нули. Это значит, что если в выражении CASE указан ELSE 0, каждая строка, не попавшая под условие, превращается в значение 0. В результате такие строки тоже попадают в подсчёт.

Вот наивный пример:

sql id="g4suvd"
SELECT
    Department,
    COUNT(CASE
              WHEN Status = 'Active' THEN EmployeeID
              ELSE 0
          END) AS ActiveEmployees
FROM Employees
GROUP BY Department;

В этом запросе каждая строка, которая не удовлетворяет условию, превращается в 0, а это валидное значение, поэтому оно тоже учитывается в COUNT. Из-за этого результат может получиться вводящим в заблуждение.

Лучше всего вообще убрать ELSE. Когда ветка ELSE опущена, выражение CASE возвращает NULL для строк, которые не соответствуют условию. А так как COUNT() игнорирует NULL, будут посчитаны только строки, которые действительно удовлетворяют условию. Вот правильный вариант:

sql id="vxa5np"
SELECT
    Department,
    COUNT(CASE
              WHEN Status = 'Active' THEN EmployeeID
          END) AS ActiveEmployees
FROM Employees
GROUP BY Department;

В этой версии строки, не подходящие под условие, возвращают NULL, и COUNT() естественным образом исключает их из подсчёта. В итоге запрос получается чище, а подсчёт корректно отражает только те значения, которые реально соответствуют условию.

👉 Java Portal

Java tip: используйте ThreadLocal.withInitial(...), чтобы у каждого потока было свое безопасное значение по умолчанию.

Значение создается лениво

👉 Java Portal

Вопрос на Java-собеседовании:

Что такое Spring Bean Scope?

Spring Bean Scope определяет жизненный цикл и область видимости бина в контейнере.

Основные типы:

- singleton (по умолчанию) — один экземпляр на весь контейнер.
- prototype — новый экземпляр для каждого запроса.
- request — бин живет в рамках одного HTTP-запроса.
- session — бин живет в рамках одной HTTP-сессии.
- application — бин живет в рамках всего веб-приложения.
- websocket — бин живет на протяжении сессии WebSocket.

👉 Java Portal