Вопросы на собеседовании: .NET-разработчик

Я бы сначала изолировал fulfillment как бизнес-возможность, но до выделения задал ему явный контракт и владение данными внутри монолита.

• Определяю инварианты резервирования, упаковки и отправки и оставляю операции одной транзакции внутри границы fulfillment.
• Другие модули прекращают напрямую писать в таблицы fulfillment и вызывают внутренний facade до его превращения в HTTP, gRPC или messaging.
• Transactional outbox публикует события готовности заказа, а fulfillment владеет своей write model и идемпотентно потребляет события.
• Выделение оправдано, когда отдельные worker и база докажут пятикратную ёмкость записи без межсервисных транзакций.

Я бы оставил синхронными только решения, необходимые для ответа, а распространение состояния перенёс в надёжные сообщения.

• Pricing и резерв inventory могут параллельно идти по gRPC с общим дедлайном около 450 мс, оставляя checkout время собрать результат.
• Fraud использует синхронное быстрое решение только если без него нельзя продолжить; глубокая проверка становится pending workflow, а не ещё одним долгим hop.
• Письмо подтверждения, аналитика и warehouse projection потребляют outbox events после commit транзакции checkout.
• Я отклоню цепочку, где каждый сервис получает собственный timeout 600 мс, потому что задержка и вероятность отказа растут на каждом hop.

Я бы оставил request path stateless, агрессивно кэшировал read models и ограничил каждую общую зависимость.

• Kestrel instances стоят за zone-aware load balancer, раздельно показывают readiness и liveness и сохраняют минимум 30% ёмкости после потери одной зоны.
• CDN обслуживает публичные immutable responses, Redis хранит общие проекции товаров, а малый IMemoryCache принимает самые горячие versioned keys.
• EF Core проецирует только нужные поля с AsNoTracking, а конкурентность соединений SQL Server ограничена и не растёт вместе с числом pods.
• Нагрузочные тесты используют реальное распределение ключей и требуют p99 ниже 120 мс при 125 000 RPS и отключённой зоне.

Я бы упорядочил middleware по состоянию запроса, которое каждый компонент должен установить или защитить.

• Forwarded headers идут первыми для доверенных proxies, затем exception handling и HSTS задают правильную схему и единые ошибки до прикладной работы.
• Routing выбирает endpoint metadata до того, как CORS, authentication, authorization и endpoint-specific rate limiting используют эти metadata.
• Authentication предшествует authorization, а CORS запускается до формирования ответа, чтобы даже отклонённые cross-origin requests получили правильные headers.
• Проверяю порядок integration tests для preflight, unauthenticated, forbidden, rate-limited и throwing endpoints, а не визуально.

Я бы группировал minimal APIs по возможностям и явно задавал контракт каждого endpoint при регистрации.

• MapGroup применяет route prefixes, tags, authorization policies и общие conventions к областям вроде orders или billing.
• TypedResults и именованные request records делают response unions и OpenAPI metadata видимыми компилятору вместо возврата произвольного IResult повсюду.
• Endpoint filters обрабатывают повторную request validation, а middleware остаётся для pipeline-wide concerns вроде correlation и exception mapping.
• Contract tests генерируют OpenAPI и проверяют все 180 operations на случайное удаление, новые required fields и изменённые status codes.

Я бы стримил каждое body прямо в надёжное хранилище и отклонял слишком большие или медленные загрузки до буферизации.

• Kestrel и reverse proxy одинаково задают лимит 2 ГБ, header timeout и minimum data rate, чтобы ограничения нельзя было обойти на другом слое.
• Endpoint читает Request.BodyReader ограниченными сегментами и пишет в multipart upload blob storage без ToArray и binding файла целиком.
• Semaphore ограничивает активные записи в хранилище по измеренной bandwidth, а отмена запроса прерывает multipart upload и освобождает ресурсы.
• Load test запускает 200 потоков максимального размера и доказывает ограниченную managed memory вместо роста вместе с байтами загрузок.

Я бы добавил понятие без обязательности для старых клиентов, а ломающую смену семантики провёл как миграцию.

• Первый контракт добавляет optional deliveryPreference, а при его отсутствии сервер сохраняет прежнее поведение по умолчанию.
• OpenAPI compatibility checks запрещают удаление, сужение типов и новые required fields в существующей версии.
• Usage telemetry находит клиентов без поля, а инструкция миграции содержит их точный endpoint и дату последнего использования.
• Только через 12 месяцев новая датированная версия потребует поле, а старая до удаления сохранит исходный смысл.

Я бы исключил отказ зависимостей из liveness и использовал readiness, чтобы прекратить отправку запросов в неспособные обслуживать pods.

• Liveness проверяет только способность процесса и его внутреннего цикла двигаться, поэтому отказ SQL Server не создаёт restart storm из 80 pods.
• Readiness может включать короткую проверку базы, если API действительно не работает без неё, с hysteresis против частого flapping endpoint.
• Startup покрывает migrations, configuration validation или warmup, которые законно дольше обычного liveness timing.
• Tests отключают SQL Server на 40 секунд и требуют ноль перезапусков, отсутствие трафика на unready pods и автоматическое восстановление.

Я бы отделил неизменные startup options от малого versioned secret, который безопасно перезагружать.

• Endpoint, timeout и retry limits связываются со strongly typed options и вызывают ValidateOnStart, чтобы неверные значения не прошли readiness.
• Credentials приходят из managed secret provider через IOptionsMonitor, а consumers атомарно меняют полный immutable credential snapshot.
• Reload никогда не меняет endpoint и credential частично, а старый credential остаётся рабочим в документированном overlap window.
• Integration tests ротируют secret под 1 000 конкурентных вызовов и проверяют отсутствие смешанной конфигурации.

Я бы использовал spans для slicing и parsing существующего буфера без substrings, но только после подтверждения горячего parser в allocation profile.

• ReadOnlySpan<byte> может искать delimiters и разбирать numeric fields прямо из request buffer без временных strings.
• Span нельзя хранить в heap или держать через await, поэтому нужные позже данные становятся owned value или Memory<byte>.
• Возврат span в pooled buffer небезопасен после возврата этого buffer, поэтому ownership важнее заявления о zero allocations.
• BenchmarkDotNet должен показать снижение аллокаций и рост throughput на реальном распределении headers, не только на маленьком synthetic input.

Я бы передавал owned Memory<byte> через асинхронные границы и создавал короткие spans только внутри синхронного parsing.

• Span<byte> нельзя держать через await, а Memory<byte> можно сохранить в item этапа и нарезать без копирования.
• Owner должен жить дольше всех 3 этапов, поэтому pooled IMemoryOwner<byte> освобождается лишь после завершения последнего consumer.
• Этап, сохраняющий данные дольше окна владения, получает копию, потому что use-after-return corruption хуже одной измеренной аллокации.
• Stress test независимо задерживает этапы и проверяет checksums, выявляя lifetime bugs, незаметные обычному throughput test.

Я бы выделял на stack только небольшой фиксированный диапазон, а выше использовал pooled или heap memory.

• Политика вроде stackalloc до 1 КБ ограничивает расход stack независимо от контролируемого атакующим input.
• Большие buffers арендуются из ArrayPool<byte> внутри try-finally, а чувствительные bytes очищаются перед возвратом.
• stackalloc не используется внутри loop, потому что повторные allocations остаются до выхода метода и могут исчерпать stack.
• Benchmarks включают recursion depth и конкурентную request load, а не только наносекунды отдельного метода.

Я бы пулил большие повторно используемые buffers, если profiling связывает их с Gen 2 или LOH pressure, а ownership остаётся простым.

• ArrayPool<byte> может вернуть больший грязный array, поэтому callers отслеживают valid length и очищают customer data перед возвратом.
• Каждая аренда имеет return в finally, и ни одна async operation не сохраняет array после возврата.
• Ограничиваю retained bucket sizes или использую custom pool, если редкие payloads по 20 МБ удерживают лишнюю память.
• Решение требует снижения allocation rate и GC pause time при том же throughput, а не только более быстрого microbenchmark.

Я бы убрал object boundary на измеренном горячем пути через generics или span-based formatting.

• Generic method с constrained formatting сохраняет value types без boxing, а TryFormat пишет прямо в destination span.
• Проверяю IL или allocation profiles для подтверждения boxing, а не считаю, что каждый interface call выделяет память.
• Structs остаются маленькими, immutable и value-like; превращение крупных mutable domain objects в structs добавит copying и semantic risk.
• Benchmark сообщает operations per second и allocated bytes, а существующий object API сохраняется вне hot formatter при необходимости совместимости.

Я бы тестировал репрезентативные payloads и аллокации в контролируемом harness, а победителя проверил на end-to-end path.

• Suite покрывает маленькие, median, large, valid и malformed inputs, а текущий parser отмечен как Baseline.
• MemoryDiagnoser показывает allocated bytes и GC counts, а warmup и несколько iterations снижают шум JIT и timer.
• Inputs реально потребляются, чтобы dead-code elimination не удалил parsing, и каждый benchmark использует одинаковые runtime и deployment architecture.
• Выигрыш microbenchmark в 25 нс важен лишь при измеренном bottleneck parser и заметном улучшении throughput или CPU сервиса.

Эти buffers обычно попадают в Large Object Heap, поэтому постоянный churn может вызвать дорогие Gen 2 collections и нарушить цель пауз.

• Gen 0 оптимизирован для короткоживущих малых объектов, но LOH objects собираются вместе с Gen 2 даже при короткой жизни.
• При 8 000 allocations в секунду сначала применяю streaming, сокращение или pooling 90 КБ buffer, а не подстраиваю GC под лишний churn.
• dotnet-counters и trace должны связать allocation rate, LOH size, Gen 2 frequency и pause duration с request load.
• Pooling принимается только с bounded retention и безопасным ownership, потому что большой pool может заменить паузы resident memory.

Я бы предпочёл строго рассчитанный NoGCRegion, только если allocation ceiling на 400 мс измерен и соблюдаем.

• TryStartNoGCRegion получает достаточно места под известный allocation budget, а код обрабатывает невозможность входа вместо предположения о гарантии.
• EndNoGCRegion запускается в finally, а monitoring фиксирует неожиданный GC из-за превышения budget.
• SustainedLowLatency шире и может откладывать intrusive collections ценой роста heap, поэтому подходит более длинному ограниченному периоду с менее предсказуемыми allocations.
• Сначала уменьшаю allocations, потому что latency modes не делают тяжёлый по аллокациям путь бесплатным.

Я бы сравнил оба режима в реальном container, потому что server GC может обменять дополнительные heaps и memory на throughput.

• Server GC использует dedicated collection threads и несколько heaps, что помогает устойчивой параллельной нагрузке, но заметно расходует лимит 768 МБ.
• Workstation GC может лучше подойти малому ограниченному process при умеренных request concurrency и live set.
• Test сравнивает throughput, p99 pause, GC CPU, heap size и working set при одинаковых load и CPU quota.
• До выбора быстрого результата оставляю non-GC headroom на thread stacks, native buffers, JIT code и libraries.

Я бы бюджетировал весь process, а не приравнивал managed heap size к памяти container.

• Thread stacks, native HTTP buffers, compression, JIT code, mapped files и allocator fragmentation могут объяснить оставшиеся 182 МБ.
• GC heap hard limit оставляет измеренный native headroom, например 300 МБ только после наблюдения peak non-GC use под реальным трафиком.
• Уменьшение heap повышает collection frequency, поэтому до rollout сравниваю p99 latency, GC CPU и allocation rate.
• Лимиты pod и heap тестируются на maximum concurrency и больших payloads с safety margin, а не по average working set.

Я бы рассмотрел ValueTask<T> только после доказательства существенной цены Task allocation на этом объёме и сохранил single-consumption semantics.

• Синхронный hit может вернуть значение без нового Task<T>, а 3% асинхронных misses оборачивают настоящую operation.
• ValueTask<T> является более крупным struct и обычно await один раз, не кэшируется, не хранится широко и не потребляется повторно.
• Если реализация уже возвращает cached Task<T>, ValueTask может добавить сложность без удаления allocations.
• Benchmark должен включать callers, потому что copying, AsTask conversions и async state machines могут съесть локальный выигрыш.