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.
C++ (направление)Обосновывает выбор между подходами к управлению памятью/производительностью (`unique_ptr` vs `shared_ptr` с учётом overhead подсчёта ссылок, move semantics vs копирование) с указанием измеримого эффекта (снижение аллокаций/копий); диагностирует утечку памяти или undefined behavior инструментом (Valgrind/ASan) и объясняет причину по отчёту.