Вопросы на собеседовании: Фулстек-разработчик

Определите один обобщённый интерфейс и реализуйте его под каждый бэкенд за инверсией зависимостей.

• Объявите базовый Repository<T, ID> с findById, save, delete и findMany.
• Добавьте конкретные SqlRepository<T> и NoSqlRepository<T>, реализующие контракт.
• Ограничьте ID типом string | number вторым дженериком, под бэкенд.
• Внедряйте реализацию, чтобы код зависел от интерфейса, а не от хранилища.
• Меняйте бэкенд в тестах или миграциях без правки бизнес-логики.

Конкурентный рендеринг позволяет React прерывать и возобновлять работу, чтобы срочный ввод оставался отзывчивым.

• startTransition оборачивает несрочное обновление, чтобы React мог его прервать.
• useDeferredValue оборачивает значение, рендеря со старым, пока не освободятся ресурсы.
• Берите startTransition, когда сеттер состояния ваш.
• Берите useDeferredValue, когда значение приходит из пропса или контекста.

Сначала измерьте, затем уберите блокирующую работу с event loop.

• Снимайте задержку через perf_hooks.monitorEventLoopDelay, clinic.js или 0x.
• Ищите синхронный JSON больших payload, синхронные вызовы fs, плотные циклы.
• Переносите CPU-тяжёлую работу в worker threads и батчите синхронные операции.
• Используйте setImmediate для передачи управления между большими итерациями.
• Добавьте трассировочные spans, чтобы связать задержку с типами запросов под нагрузкой.

Разделите систему на быстрые распределённые записи и чтения с CDN.

• Генерируйте ID через Snowflake или диапазоны из счётчика, затем кодируйте в base62.
• Храните маппинг slug в URL в DynamoDB или Redis Cluster с большим TTL.
• Ставьте перед чтениями CloudFront или Cloudflare Workers, чтобы редиректы не доходили до оригина.
• Используйте consistent hashing по шардам для распределения нагрузки записи.
• Добавьте Bloom-фильтр для отклонения невалидных slug до обращения к базе.

Подбирайте индекс под способ фильтрации запроса: подмножество строк или несколько столбцов.

• Берите partial index, когда запрос всегда фильтрует высокоселективное подмножество, например status = 'pending'.
• Берите composite index, когда запросы фильтруют или сортируют по нескольким столбцам сразу.
• Совмещайте их в частичный составной индекс, когда выполнены оба условия.
• Проверяйте pg_stat_user_indexes, ведь неиспользуемые индексы замедляют запись.

App Router по умолчанию рендерит на сервере и кэширует на уровнях запроса, маршрута и данных.

• Компоненты по умолчанию серверные, отдают HTML без своего JS в бандле.
• Границы Suspense стримят оболочку первой и сбрасывают секции по мере готовности данных.
• Кэш охватывает дедуп fetch в запросе, кэш маршрутов и кэш данных.
• Сбрасывайте кэш через revalidatePath, revalidateTag или fetch с cache: 'no-store'.

BFF формирует данные под одного клиента, шлюз решает сквозные задачи для всех.

• BFF принадлежит фронтенд-команде и подгоняет контракт под одну поверхность UI.
• API-шлюз централизует аутентификацию, лимиты, маршрутизацию и трансляцию протоколов.
• BFF добавляет сервис на каждый тип клиента, но даёт фронтенду автономию.
• Шлюз, единая точка, проще в эксплуатации, но копит смешанные задачи и тормозит правки контракта.

Батчите вызовы резолверов через DataLoader и ограничивайте стоимость запроса до выполнения.

• Используйте DataLoader для батчинга вызовов уровня поля за тик и дедупа по ключу.
• Создавайте экземпляры DataLoader per-request, чтобы не утекали данные между пользователями.
• Добавьте анализ сложности, присваивающий стоимость полям и отклоняющий запросы выше порога.
• Кэшируйте на сервере по нормализованному AST, чтобы избежать лишних обращений к базе.

Используйте скользящее окно в Redis на атомарном Lua-скрипте.

• Храните хэш на пользователя по временному окну и инкрементируйте в Lua-скрипте.
• Lua выполняется атомарно на одном шарде, убирая гонки без внешних блокировок.
• Делайте ключи по времени и EXPIRE, чтобы Redis сам чистил старые окна.
• Добавьте локальный in-memory слой для поглощения всплесков до обращения к Redis.

Ставьте requests на базовую нагрузку, limits на безопасный максимум и калибруйте под нагрузкой.

• requests отражают типичное потребление, чтобы планировщик точно размещал поды.
• limits ограничивают потребление до вмешательства Kubernetes.
• Слишком низкий лимит памяти запускает OOMKiller и каскад перезапусков.
• Слишком низкий лимит CPU молча троттлит Node.js, повышая задержку event loop.
• Профилируйте под реальной нагрузкой и ставьте память чуть выше пика для пиков GC.

Предпочитайте COPY для простого переноса и упорядочивайте слои, чтобы зависимости кэшировались отдельно от кода.

• COPY только переносит файлы из контекста сборки в образ.
• ADD ещё распаковывает tar-архивы и качает по URL, что делает его непредсказуемым.
• Docker кэширует слой по инструкции и входам; одна инвалидация пересобирает все следующие.
• Копируйте package.json и lock-файлы, запускайте npm install, затем код, чтобы правки кода не сбрасывали слой зависимостей.

Lambda подходит для лёгких всплесков, Fargate для тяжёлых и долгих задач, поэтому совмещайте их.

• Lambda ограничена 15 минутами, 10 GB эфемерного хранилища и 3 GB памяти.
• Cold start добавляет 500 мс, 2 секунды, что недопустимо для синхронных запросов.
• Fargate запускает постоянные контейнеры без таймаута и без cold start.
• Держите API на Fargate для лёгкой синхронной работы, тяжёлые трансформации выносите в Lambda через SQS.

Выявите дрейф через plan, затем импортируйте или откатывайте и закройте будущие правки.

• Запустите terraform plan для сравнения состояния с реальной инфраструктурой.
• Сохраните ручное изменение, импортировав ресурс через terraform import.
• Откатите ненужное изменение, применив объявленную конфигурацию.
• Проводите планы через CI/CD и ловите внеполосные правки через AWS Config.
• Блокируйте состояние через S3 и DynamoDB, чтобы исключить параллельные apply.

Горутины дёшевы из-за крошечных растущих стеков и M:N-планирования, но утекают, если их не отменять.

• Они стартуют с нескольких килобайт растущего стека против мегабайтов у потоков ОС.
• Среда выполнения мультиплексирует тысячи горутин на немного потоков через M:N-планировщик.
• Утечки возникают, когда горутина вечно блокируется на незакрытом канале или неотменённом контексте.
• Связывайте каждый запуск с отменой, передавайте context.Context и запускайте goleak в тестах.

Расскажите конкретную историю, где вы предложили альтернативу вместо простого «нет».

• Возьмите случай со скрытой сложностью: нехватка инфраструктуры или риск миграции.
• Покажите, что подготовили конкретную альтернативу с анализом затрат и выгод.
• Опишите, как представили её PM и дизайну и согласовали поэтапный подход.
• Завершите результатом и уроком о том, как объяснять ограничения нетехническим стейкхолдерам.

Параметризуйте всё и валидируйте ввод на границе.

• Используйте параметризованные запросы или prepared statements вместо конкатенации ввода.
• В билдере вроде Knex применяйте привязку параметров и не интерполируйте вручную.
• Избегайте exec и eval; используйте child_process.execFile с явным массивом аргументов.
• Валидируйте запросы через Zod или Joi, чтобы невалидный ввод отклонялся рано.

Event sourcing хранит полную историю событий и получает состояние их воспроизведением.

• Он хранит неизменяемые события вместо перезаписи состояния, восстанавливая его с снапшота или начала.
• Вы получаете полный audit trail, воспроизводимую историю и поддержку event-driven.
• Он подходит для аудит-комплаенса, нескольких read-проекций и временных запросов «состояние на дату X».
• Он добавляет сложность снапшотов и эволюции схем, поэтому избыточен для простого CRUD.

Разбейте тесты по слоям и проверяйте идемпотентность, ведь доставка «ровно один раз» не гарантирована.

• Юнит-тестируйте отдельные обработчики с мокированным клиентом очереди.
• Контракт-тестируйте продюсера и консьюмера против общего реестра схем.
• e2e-тестируйте против эмулятора: LocalStack для SQS или Testcontainers для Kafka.
• Добавьте тесты идемпотентности на повторную доставку и trace ID, чтобы сбои в CI были диагностируемы.

Federation даёт каждому сервису владеть частью одного графа, а шлюз компонует их во время запроса.

• Каждый subgraph определяет свою часть, а шлюз разрешает межсервисные сущности через @key.
• Schema stitching связывает шлюз со схемами сервисов и логикой резолверов.
• Federation хранит правила композиции в каждом сервисе, поэтому они деплоятся независимо.
• Главная сложность, автоматизация пересборки supergraph через реестр вроде Apollo Studio.

Снижайте scale factor на уровне таблицы, чтобы vacuum шёл часто, а не после сильного раздутия.

• Autovacuum срабатывает, когда мёртвые кортежи превышают threshold плюс scale_factor на число строк.
• Дефолтный 0,2 ждёт, пока 20% таблицы станет мёртвым, вызывая раздутие и конкуренцию.
• Переопределите на таблице autovacuum_vacuum_scale_factor = 0,01 и autovacuum_vacuum_cost_delay = 2ms.
• Мониторьте n_dead_tup и last_autovacuum, чтобы vacuum успевал за записью.