API и сетевые протоколы (Skill Passport)Обосновывает выбор между REST/gRPC/GraphQL для конкретного кейса, указывая минимум два trade-off (например: задержка vs гибкость схемы, строгая типизация контракта vs скорость разработки клиента).
БД/SQLОбосновывает выбор между нормализацией и денормализацией схемы для конкретной нагрузки с указанием, что именно меняется (число запросов, объём хранимых данных); сравнивает минимум две стратегии шардирования/партиционирования и объясняет, для какого паттерна нагрузки подходит каждая; обосновывает выбор уровня изоляции транзакций для конкретного сценария (например, финансовая операция vs аналитический отчёт), явно называя, каким риском (аномалией) жертвует ради производительности при более слабом уровне.
System DesignПроектирует систему с явным разбором альтернатив по нагрузке/консистентности/стоимости — не абстрактно, а с конкретными числами (сколько запросов в секунду, какая консистентность нужна и почему).
Message queuesОбосновывает выбор между Kafka/RabbitMQ/SQS (или аналогами) для конкретного сценария по минимум двум критериям (порядок сообщений, пропускная способность, задержка, повторная обработка); проектирует стратегию обработки дублей и падений consumer (idempotency key, dead-letter queue).
Микросервисная архитектураОбосновывает решение о разделении или объединении сервисов с конкретными trade-off (операционная сложность, latency цепочки вызовов, зоны отказа); проектирует стратегию отказоустойчивости (circuit breaker, retry с backoff, timeout) для цепочки из 3+ сервисов.
Кэширование (Redis)Обосновывает выбор стратегии инвалидации кэша (TTL, event-based инвалидация, write-through/write-behind) для конкретного кейса, называя, какую проблему решает каждая; проектирует защиту от cache stampede (блокировка, jitter в TTL) при пиковой нагрузке.
Тестирование кодаОбосновывает выбор уровня тестирования (unit vs интеграционный vs e2e) для конкретного риска бага — что проверяет каждый уровень и почему остальные избыточны или недостаточны; обосновывает необходимость contract-тестов между двумя конкретными сервисами для конкретного сценария поломки контракта (например, изменение формата ответа одним сервисом незаметно ломает потребителя).
Docker/контейнеризацияОбосновывает выбор базового образа и стратегии сборки минимум по двум критериям (размер образа, время сборки, безопасность — например, переход на distroless/alpine); проектирует контейнеризацию сервиса для оркестрации (Kubernetes/аналог) — health-check, resource limits, graceful shutdown.
Java/KotlinОбосновывает выбор между подходами внутри Java/Kotlin-стека (например, потокобезопасность через `synchronized` vs `java.util.concurrent`, immutability через `val`/data class в Kotlin) с указанием рассмотренных альтернатив; объясняет happens-before на конкретном примере гонки данных и как её устраняет выбранный примитив синхронизации; диагностирует утечку памяти по хипдампу на уровне, достаточном для локализации причины.
SpringОбосновывает выбор между конфигурациями Spring для задачи (synchronous MVC vs WebFlux/reactive, стратегия транзакций при межсервисном вызове) с указанием trade-off; диагностирует проблему конфигурации контекста (circular dependency, некорректный bean scope) по стектрейсу.