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# (направление)Обосновывает выбор между подходами внутри C#-стека (`IEnumerable` с отложенным выполнением vs материализованный `List`, стратегия обработки исключений в async-коде) с указанием рассмотренных альтернатив; диагностирует проблему производительности сборщика мусора (частые Gen0-сборки) по профилировщику.
.NET/ASP.NETОбосновывает выбор между конфигурациями .NET для задачи (минимальные API vs контроллеры, стратегия middleware pipeline) с указанием trade-off; диагностирует проблему конфигурации DI (некорректный lifetime — Singleton/Scoped/Transient) по симптому в проде.