Вопросы на собеседовании: Ruby-разработчик
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior Ruby-разработчик.
Смотреть пример резюме: Ruby-разработчик →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я не могу подобрать Puma только по RPS и p99; нужны измеренные средняя занятость запроса, CPU на запрос и RSS каждого worker под реалистичной нагрузкой.
- При средней занятости 50 мс закон Литтла даёт 4000 умножить на 0,05, то есть 200 одновременных слотов до запаса; p99 не заменяет это среднее значение.
- Число workers проверяю относительно CPU восьми pod и лимита 1,5 GiB, а threads добавляю лишь там, где ожидание PostgreSQL или HTTP повышает throughput без исчерпания пулов ActiveRecord.
- k6 только создаёт traffic, а метрики инфраструктуры измеряют backlog Puma, CPU, RSS и run queue операционной системы; оставляю конфигурацию, которая держит p99 без постоянного насыщения.
Зачем это спрашивают: Интервьюер проверяет подбор Puma по измеренной занятости и ресурсным лимитам, а не только по RPS и p99.
Я ограничу pool каждого worker семью соединениями вместо того, чтобы отдать все 320 соединений 288 web threads.
- Двенадцать умножить на три и семь дают 252 web-соединения, оставляя 68 для migrations, consoles, monitoring и failover.
- Пулы primary, replica и Sidekiq считаются отдельно, потому что каждый process и database role владеют своим pool.
- Требую p99 ожидания checkout ниже 10 мс; если семи мало, сокращаю занятость запросами или добавляю PgBouncer, а не превышаю бюджет базы.
Зачем это спрашивают: Интервьюер оценивает расчёт соединений и эксплуатационный запас для разных типов процессов.
Я вынесу identity и workflow state из Puma, чтобы следующий запрос обслужил любой здоровый pod.
- Для сессий использую подписанные шифрованные cookies меньше 4 KB или opaque IDs в Redis, если нужен отзыв.
- Загрузки идут прямо в object storage по presigned URL на 10 минут; запрос не зависит от файловой системы pod или memory cache.
- Orders и idempotency keys хранятся в PostgreSQL с unique constraints, а termination завершает активные запросы за 30 секунд без sticky sessions.
Зачем это спрашивают: Интервьюер проверяет устранение скрытой привязки к инстансу с сохранением корректности.
Я использую CDN, fragments в Redis и memoization на время запроса с отдельным контрактом свежести для каждого слоя.
- CDN кэширует публичный JSON 30 секунд со stale-while-revalidate 60 секунд; hit rate 95% сокращает origin load примерно до 750 RPS.
- Redis хранит собранный товар 120 секунд под versioned key вроде product:42:v17; память процесса не является общим cache.
- Memoization убирает повторные policy и association внутри одного request, а hit ratio и origin p99 измеряются по каждому слою.
Зачем это спрашивают: Интервьюер проверяет явную свежесть и количественное снижение нагрузки на каждом слое cache.
Я выведу keys из версий базы и дополню event invalidation TTL в 60 секунд.
- Product fragments используют cache_key_with_version, а categories один content_version вместо touch миллионов дочерних rows.
- Transaction обновления увеличивает version и пишет outbox row, поэтому invalidation не исчезнет после commit.
- Consumers удаляют keys Redis и CDN по явному surrogate key; wildcard SCAN по 20 миллионам keys слишком медленный и шумный.
Зачем это спрашивают: Интервьюер оценивает транзакционную инвалидацию и жёсткую границу устарелости при большом числе keys.
Я разделю нагрузки по processes с явной concurrency, чтобы медленные exports не занимали payment threads.
- Payments получают 24 threads и SLO queue latency ниже 2 секунд, emails 32 и 30 секунд, exports 24 и 10 минут.
- Strict priority оставлю маленькому critical process, потому что постоянно занятая первая queue вызывает starvation следующих.
- Отдельные Kubernetes deployments изолируют exports по 2 GiB и масштабируются по queue latency и execution time, а не только по длине queue.
Зачем это спрашивают: Интервьюер проверяет преобразование бизнес-классов задержки в конкретные границы Sidekiq.
Я сделаю идемпотентной операцию базы, а Sidekiq uniqueness использую только для сокращения лишней работы.
- Job принимает payment_id и вставляет capture под unique index по payment_id и provider_operation.
- Одна transaction блокирует payment, создаёт или находит capture и пишет outbox event; retry возвращает сохранённый результат.
- unique_for может подавлять дубликаты 30 минут, но provider получает тот же idempotency key, потому что Redis lock не является 24-часовой границей корректности.
Зачем это спрашивают: Интервьюер проверяет долговечную идемпотентность на границах queue, database и provider.
Цель равна 2500 jobs в секунду, что требует около 400 конкурентных слотов и 100 CPU cores до запаса.
- Три миллиона разделить на 1200 секунд дают 2500 jobs в секунду; 2500 умножить на 160 мс дают 400 in-flight jobs.
- CPU demand равен 2500 умножить на 40 мс, то есть 100 CPU-секунд в секунду, поэтому с запасом 30% нужно около 130 cores.
- Несколько processes используют cores несмотря на GVL, а около четырёх threads на process перекрывают I/O; load test включает Redis, database pools и object storage.
Зачем это спрашивают: Интервьюер оценивает расчёт throughput и различие между thread concurrency и CPU capacity.
Я сопоставлю partial composite index с точным tenant predicate и сортировкой.
- Для tenant_id, open status и created_at DESC проверю индекс по tenant_id, created_at DESC where status = 'open'.
- Если открыты только 4% orders, partial index примерно в 25 раз меньше индекса по всем status.
- INCLUDE id и total_cents могут дать index-only scans, но я приму их только когда EXPLAIN ANALYZE покажет мало heap fetches и допустимую стоимость записи под нагрузкой.
Зачем это спрашивают: Интервьюер проверяет вывод индекса из реального query с количественной селективностью и стоимостью записи.
Я использую INCLUDE columns только если index-only scans экономят достаточно heap I/O для компенсации тяжёлых writes.
- Search columns остаются B-tree keys; в INCLUDE попадают только стабильные projected columns, потому что они не влияют на ordering.
- Пять широких columns могут увеличить индекс с 40 GB до 80 GB и удвоить его WAL, поэтому я считаю bytes, а не называю coverage бесплатным.
- Частые writes сбрасывают visibility bits, поэтому сравниваю heap fetches, WAL и replica lag через EXPLAIN (ANALYZE, BUFFERS) на production-like traffic.
Зачем это спрашивают: Интервьюер оценивает ограничения visibility map и write amplification от covering indexes.
Я направлю критичные reads на primary в ограниченном окне, а browsing оставлю на replicas.
- После создания order ответ несёт signed primary-read token на 10 секунд; checkout GET с ним использует writing role.
- Search и reviews допускают lag 500 мс и сохраняют большую часть разгрузки 70%.
- Границы ActiveRecord connected_to задаются явно, потому что переключение по HTTP verb не понимает POST, затем GET; alert срабатывает до достижения token window.
Зачем это спрашивают: Интервьюер проверяет явную семантику согласованности вместо одинакового отношения ко всем replica reads.
Сначала я сделаю range partitioning по месяцам, а sharding введу после измеренного лимита одного primary.
- Месячные partitions около 2 TB дают pruning запросов по времени и превращают retention 24 месяца в быстрый DROP вместо огромного DELETE.
- Queries включают occurred_at, а локальные indexes начинаются с tenant_id, occurred_at, совмещая pruning и tenant access.
- Sharding добавляет routing, resharding и cross-shard aggregation; его trigger, например, storage 70% или WAL выше capacity replicas.
Зачем это спрашивают: Интервьюер оценивает наименее сложную границу масштабирования по измеренным лимитам узла.
Я ограничу depth и учитывающую cardinality complexity до выполнения, затем добавлю runtime deadlines.
- Начну с max_depth 12 и max_complexity 200, причём connection fields платят по запрошенному page size, а не одну фиксированную единицу.
- first ограничен 100, а unbounded lists отклоняются, не позволяя aliases умножать resolvers на миллион строк.
- Каждый request получает deadline 400 мс и PostgreSQL statement_timeout около 350 мс, а persisted trusted operations получают проверенные budgets.
Зачем это спрашивают: Интервьюер проверяет многоуровневые GraphQL controls, учитывающие cardinality результата.
Я буду batch-загружать associations по key через GraphQL::Dataloader, сохраняя постоянное число queries при росте страницы.
- Один source загружает customers по ID, второй items по order_id, сокращая примерно 201 query до трёх.
- Sources сохраняют порядок результатов и возвращают nil для missing keys, чтобы records не прикрепились к неверному parent.
- Orders ограничены 100, items 50, а ActiveSupport instrumentation и test падают, если operation превышает пять SQL queries.
Зачем это спрашивают: Интервьюер оценивает корректный bounded batching, защищённый tests числа queries.
Я использую opaque keyset cursors по стабильной compound ordering вместо OFFSET.
- Cursor кодирует created_at и id, соответствуя index по account_id, created_at DESC, id DESC.
- Следующая страница использует (created_at, id) < (?, ?) и LIMIT 101 для has_next_page без COUNT(*).
- Page size ограничен 100, cursors подписаны; OFFSET 1000000 отбрасывает миллион entries и смещается при inserts.
Зачем это спрашивают: Интервьюер проверяет стабильную pagination, соответствующий индекс и инкапсуляцию API в масштабе.
Я делаю additive changes в текущей версии, а новую оставляю для semantic breaks с измеримым migration window.
- OpenAPI является reviewed source; CI блокирует удалённые fields, суженные enums и новые required inputs.
- Consumer contracts покрывают пять самых нагруженных clients, а telemetry отслеживает version и field use всех 40.
- Breaking v2 работает рядом с v1 90 дней с Sunset metadata и owner для каждого оставшегося client.
Зачем это спрашивают: Интервьюер оценивает исполняемую совместимость и конкретный процесс вывода версии.
Я подтверждаю только долговечный приём, а работу отправляю из database inbox, не из callback after_commit.
- Unique index по provider и provider_event_id определяет identity события, а HMAC покрывает raw body и timestamp с replay window пять минут; duplicates получают тот же 2xx.
- Controller вставляет inbox row в короткой transaction и возвращает 202 за 300 мс, а contract задаёт лимит body 10 MB, schema version и retention 72 часа.
- Pollers забирают committed inbox rows через FOR UPDATE SKIP LOCKED, ставят в queue сохранённый ID и отмечают отправку; crash может дать duplicate, поэтому worker обрабатывает этот ID идемпотентно.
Зачем это спрашивают: Интервьюер проверяет долговечный приём webhook без окна потери при enqueue после commit.
Я сохраню один deployment, но создам исполняемые package boundaries вокруг бизнес-доменов.
- Packwerk packages владеют models, jobs, controllers и public APIs; CI отклоняет новые privacy и dependency violations.
- Billing обращается к Accounts через узкий interface, а прямой доступ к таблицам Billing и private constants запрещён.
- У каждого package есть owner и focused tests, но доступна одна PostgreSQL transaction; существующие violations получают baseline и удаляются по доменам.
Зачем это спрашивают: Интервьюер оценивает исполняемую модульность без преждевременной цены распределённой системы.
Я выделю его только когда domain и operational boundary окупят distributed transactions и отдельную эксплуатацию.
- Dedicated team, отдельный compliance cadence, стабильный API и особый scaling profile важнее числа classes.
- Сначала изолирую Billing за in-process interface и соберу шесть недель dependency telemetry, прекратив cross-domain table writes.
- Remote API использует крупные idempotent commands; выделение отменяется, если checkout всё ещё нужна одна синхронная transaction Orders и Billing.
Зачем это спрашивают: Интервьюер проверяет измеримые основания выделения вместо общих аргументов за microservices.
Я вставлю order и outbox row в одной PostgreSQL transaction, а затем опубликую асинхронно.
- Row содержит event_id, aggregate_id, type, schema_version, payload и created_at; event_id служит idempotency key consumer.
- Relays забирают batches через FOR UPDATE SKIP LOCKED, публикуют в Kafka и помечают sent, принимая возможный duplicate после crash.
- При 20000 в секунду partitioning идёт по дням, alert срабатывает при oldest unpublished age выше 10 секунд, а consumers обеспечивают idempotency.
Зачем это спрашивают: Интервьюер оценивает атомарное создание event и честную at-least-once delivery в масштабе.
Закрытые вопросы
- 21
Kafka Rails pipeline обрабатывает 50000 account events в секунду в 120 partitions и требует порядок внутри account; как выбрать keys?
kafkarailspartitioning - 22
Rails SaaS обслуживает 30000 tenants, включая 20 регулируемых со строгой изоляцией, на PostgreSQL 2 TB; какую модель выбрать?
postgrescloudrails - 23
Один tenant создаёт 35% traffic в SaaS на 10000 tenants, а у каждого SLA p99 500 мс; как ограничить noisy neighbor?
cloud - 24
Нужно добавить required country_code в users на 600 миллионов rows при 8000 writes в секунду; каков zero-downtime plan?
rails - 25
В payments на 900 миллионов rows нужно заменить integer cents на richer money representation с mismatch ниже 0,01%; как провести migration?
- 26
Rails endpoint тратит 70 мс CPU на JSON parsing и 30 мс ждёт PostgreSQL при цели 10000 RPS; что означает GVL?
postgresendpointsrails - 27
Pod имеет 4 vCPU и 3 GiB, каждый прогретый Ruby worker занимает 620 MiB, а workload на 60% состоит из I/O; выбрать processes или threads?
concurrencyruby - 28
Ruby service выполняет 200 CPU-heavy calculations в секунду по 25 мс в пределах 2 GiB; выбрать threads, processes или Ractors?
concurrencyruby - 29
Rails pod с лимитом 2 GiB растут с 900 MiB до 1,8 GiB RSS за шесть часов; как задать Ruby GC и memory budget?
railsmemoryruby - 30
Предзагруженный Rails pod запускает четыре Puma workers под cgroup limit 3 GiB, и каждый worker показывает RSS 600 MiB; как сохранить copy-on-write и рассчитать память?
railsmemory - 31
Rails API тратит 65% CPU в Ruby при 7000 RPS и имеет запас 250 MiB на pod; как оценить YJIT?
decision-makingapimemory - 32
Rails search endpoint нужно ускорить с p99 900 мс до 250 мс при 1500 RPS; какой profiling plan использовать?
railsendpointsprofiling - 33
Rails codebase определяет 400 fields через method_missing и должна укладываться в p99 100 мс; какие metaprogramming constraints ввести?
metaprogrammingrails - 34
Rails application на 700000 строк и 25 engineers не имеет static typing; как внедрить Sorbet без остановки 20 weekly deploys?
decision-makingdeploymentrails - 35
Typed payment service принимает 12 внешних JSON schemas и должен удерживать invalid payloads ниже 0,001%; где заканчивается Sorbet?
schema - 36
Rails admin API обновляет 60 account attributes для 5000 support agents; как предотвратить authorization и mass assignment flaws?
authapirails - 37
Rails application обслуживает 2 миллиона browser sessions и показывает user HTML; какие controls нужны для XSS и CSRF при availability 99,99%?
xsscsrfsessions - 38
Rails import service загружает 100000 customer URLs в день из Kubernetes; как ограничить SSRF без блокировки HTTPS imports?
railshttpskubernetes - 39
Rails checkout имеет monthly availability 99,95% и p99 400 мс при 9000 RPS; какую observability построить?
railsobservability - 40
Rails request проходит GraphQL, PostgreSQL, Redis, Sidekiq и Kafka, но tracing разрешён только для 1% traffic; как сохранить causality?
kafkarailsbackground-jobs - 41
Rails deployment запускает 40 Kubernetes pod при 6000 RPS и должен сохранять availability 99,99% во время releases; как настроить rollout?
kubernetesdeploymentconfig - 42
Puma pod получает 30 секунд на termination, а requests могут идти 20 секунд; как настроить probes и draining без 502?
config - 43
Traffic растёт с 1000 до 12000 RPS за пять минут, а Sidekiq latency должна быть ниже 10 секунд; как масштабировать оба слоя?
scalingbackground-jobslatency - 44
Stateless Rails API обслуживает US и EU с network latency 180 мс и checkout SLA p99 500 мс; где разместить state?
railsapilatency - 45
Публичный Rails API разрешает 600 requests в минуту на account, burst 100 и выдерживает 20000 RPS на 100 pod; как реализовать rate limit?
railsapi - 46
Rails reservation endpoint обрабатывает 1200 RPS для 50 общих seats, у каждой reservation есть event_id, и seat может удерживать только одна active reservation; какую PostgreSQL transaction использовать?
transactionspostgresendpoints - 47
Восемьдесят Rails и Sidekiq processes требуют до 20 connections каждый, но PostgreSQL допускает 400; как PgBouncer изменит дизайн?
designrailsbackground-jobs - 48
Rails platform на 1,2 миллиона строк нужно обновить с Rails 7.0 до 8.x при 50 daily deploys; как построить работу?
railsdeployment - 49
Checkout workflow охватывает order, inventory, payment и notifications и должен синхронно завершаться за 700 мс; как оформить Rails domain services?
rails - 50
Deployment включает index build на 400 миллионах rows и должен откатываться за 10 минут при 5000 writes в секунду; как провести release?
deploymentrollbackindexes - 51
Сразу после деплоя p99 эндпоинта оформления заказа на Rails вырос с 280 мс до 1,9 с, p50 остался около 90 мс, а доля ошибок ниже 0,2%. Что вы сделаете в первые 30 минут?
railsendpointsdeployment - 52
Каждый Puma-воркер стартует с RSS 420 МБ и вырастает до 1,4 ГБ за восемь часов, но после полного GC снижается только до 1,2 ГБ. Kubernetes ежедневно убивает два воркера. Как отличить удерживаемые Ruby-объекты от фрагментации аллокатора?
kubernetesruby - 53
После импорта 500 000 строк CSV в Rails-процессе стало на 6 миллионов объектов String больше, а отвести от него трафик можно только на десять минут и лишь для 2% нагрузки. Как безопасно собрать и использовать данные heap?
concurrencydata-structuresrails - 54
Во время распродажи с 4 000 запросов в секунду p99 Rails скачет на 350 мс каждые 20 секунд, а GC.stat показывает рост major_gc_count в те же моменты. CPU загружен на 65%. Как вы отреагируете?
rails - 55
После деплоя native-гема для обработки изображений восемь Puma pod по 4 vCPU показывают лишь 28% общего CPU, но запросы выполняются последовательно за 2,4 секунды, а добавление threads не помогает. Как вы проведёте инцидент?
soft-skillsincidentsdeployment - 56
Puma работает с 6 воркерами по 12 потоков. При 900 запросах в секунду CPU загружен на 45%, очередь запросов достигает 2,5 с, а дампы потоков показывают, что большинство ждёт один партнёрский API по 4 с. Что вы измените первым?
concurrencydata-structuresapi - 57
Rails-флот состоит из 10 подов, в каждом 2 Puma-воркера по 10 потоков, но PostgreSQL разрешает 160 соединений приложения. Во время всплесков ожидание checkout ActiveRecord превышает 3 с. Какое решение вы примете?
postgresormconcurrency - 58
Страница заказов Rails загружает 50 заказов за 1,4 с и выполняет 151 SQL-запрос: один для заказов, 50 для клиентов и 100 для позиций и товаров. Как вы исправите и проверите это?
sqlqueriesrails - 59
После замены preload на eager_load отчёт ActiveRecord возвращает 1,8 миллиона объединённых строк для 12 000 аккаунтов, потому что одновременно присоединяет invoices и support tickets, обе связи has_many. RSS достигает 2,2 ГБ. Что вы сделаете?
joinsorm - 60
Очередь default в Sidekiq выросла с 5 000 до 240 000 джобов за 20 минут, задержка самого старого джоба составляет 17 минут, Redis исправен, а воркеры используют лишь 35% CPU. Как вы отреагируете?
redislatencydata-structures - 61
При failover primary Redis исчезают 84000 jobs Sidekiq, потому что persistence была отключена, хотя producers уже вернули 202. Как вы восстановитесь и измените contract приёма?
redisdata-structuresbackground-jobs - 62
Партнёрский API возвращает 503 уже 40 минут. В Sidekiq накопилось 1,2 миллиона повторов, память Redis заполнена на 88%, а трафик восстановления превысит лимит партнёра в 300 запросов в секунду. Что вы сделаете?
redisapimemory - 63
Кластер Redis для Rails.cache недоступен 12 минут. CPU базы вырос с 40% до 94%, ожидание checkout достигло 1,8 с, а Sidekiq использует отдельный исправный Redis. Как сохранить API доступным?
databaseredisrails - 64
Построение кэшированной домашней ленты Rails занимает 900 мс. Пятиминутный ключ истекает одновременно на 30 подах и создаёт 6 000 запросов к БД за десять секунд. Какое изменение вы выпустите?
databasequeriescaching - 65
Rails-миграция добавляет индекс уже девять минут на таблице из 180 миллионов строк. PostgreSQL показывает блокировку вставок, ожидание checkout превышает пять секунд, а деплой ещё идёт. Что вы сделаете?
indexespostgresmigrations - 66
Два Rails-джоба обновляют строки Account и Subscription в противоположном порядке. PostgreSQL сообщает о 800 deadlock в час, а повторы Sidekiq в итоге проходят, но утраивают нагрузку. Как это исправить?
consistencyrailsbackground-jobs - 67
Плановое promotion PostgreSQL завершается за 25 секунд, но 40% Rails writes падают ещё шесть минут, потому что pooled connections указывают на старый primary. Как вы восстановитесь и предотвратите повтор?
postgresrails - 68
Rails-эндпоинт проверяет 200 подписей на запрос в чистом Ruby. Один Puma-воркер занимает ядро на 100%, добавление потоков не повышает пропускную способность, а p95 достигает 1,6 с. Что вы измените?
concurrencyrubyendpoints - 69
Rails-синглтон мемоизирует курсы валют через @rates ||= fetch_rates. При 16 Puma-потоках тесты показывают два одновременных обновления и иногда частично изменённый Hash. Как сделать это безопасным?
concurrencymemoizationtesting - 70
Прототип переносит разбор метаданных изображений в четыре Ractor, но продакшен-гем хранит конфигурацию в изменяемом состоянии класса и вызывает Ractor::IsolationError. Прототип быстрее в 1,7 раза. Оставите ли вы Ractor?
configgemsprototypes - 71
Canary Rails-сериализатора получает 5% traffic, и 1,3% направленных в него requests возвращают 500, потому что в старых строках currency равен nil, а новый код ожидает String. Что вы сделаете?
serializationdeployment-strategiesrails - 72
Rails report оставляет PostgreSQL transaction в состоянии idle девять часов; 180 миллионов dead tuples нельзя удалить, таблица orders вырастает в четыре раза, а p99 достигает 3 секунд. Что вы сделаете?
transactionspostgresrails - 73
Ротация signing keys Rails завершает 68% из двух миллионов browser sessions и делает недействительными password-reset links во время release. Что вы сделаете в инциденте и при следующей ротации?
passwordssessionsincidents - 74
После обязательного включения allowlist persisted queries GraphQL 22% requests от старых mobile builds падают с PersistedQueryNotFound. Как восстановиться, не открывая произвольные queries?
queriesgraphql - 75
Обновление заказа Rails коммитится в PostgreSQL, затем напрямую публикуется в Kafka. Сетевая ошибка после коммита оставила 2 300 отправленных заказов без событий, поэтому склад видит старые данные. Как вы исправите данные и дизайн?
postgreswarehousekafka - 76
Сервис рекомендаций замедлился с 80 мс до 6 с. Rails использует таймаут чтения 7 с и один повтор, поэтому Puma-потоки удваивают исходящие вызовы, а checkout API начинает падать по таймауту. Что вы измените во время инцидента?
resiliencerailsapi - 77
Мобильные клиенты повторяют POST /orders после таймаута в 2 с. Rails создал 186 дубликатов заказов за час, потому что первые запросы закоммитились, но ответы потерялись. Как сделать эндпоинт идемпотентным?
resiliencerailsendpoints - 78
Платёжный провайдер присылает один вебхук до 12 раз и может доставить refund до charge.succeeded. Сейчас обработчики Sidekiq добавляют одну строку ledger на каждую доставку. Каков ваш дизайн?
designbackground-jobswebhooks - 79
Kafka producer отправляет amount как object вместо integer cents; один partition Rails consumer повторяет poison record 25 минут, а lag достигает трёх миллионов. Что вы сделаете?
kafkarailspartitioning - 80
Один некорректный Sidekiq-джоб вызывает JSON::ParserError за 40 мс, повторяется тысячи раз на разных воркерах и блокирует очередь с SLO две минуты. Как вы поступите?
slobackground-jobsdata-structures - 81
Rails-backfill должен обновить 70 миллионов строк. Первая версия использует Model.all.each внутри одной транзакции, достигает RSS 9 ГБ и держит блокировки 50 минут. Как вы его перепишете?
backfillrailstransactions - 82
Rails-запрос имеет SLO 1,5 с и последовательно вызывает сервисы запасов и налогов. Их p99 равны 700 и 900 мс, а каждый клиент делает один повтор с таймаутом 1 с. Что вы измените?
resilienceslorails - 83
После добавления HTTP-вызова внутрь транзакции ActiveRecord пул БД остаётся заполненным на 100%, когда партнёр отвечает три секунды. В пуле 20 соединений, Puma использует 20 потоков. Что вы переработаете?
databasetransactionsorm - 84
После прогрева четыре Puma-воркера показывают RSS 480 МБ, 490 МБ, 910 МБ и 930 МБ. Два больших воркера получают большинство долгих WebSocket-соединений и перезапускаются каждые шесть часов. Как вы исследуете и смягчите проблему?
websockets - 85
У Rails JSON API heap_live_slots стабилен после прогрева, но RSS растёт с 500 до 850 МБ во время всплесков и оседает на 760 МБ. Переход на jemalloc снижает стабильный RSS до 610 МБ, но добавляет runtime-зависимость. Что вы решите?
railsapidependencies - 86
stackprof показывает, что Rails-сериализатор выделяет 1,6 миллиона Array в секунду, потому что многократно вызывает map, compact и flatten для одних записей. CPU загружен на 78%, а GC занимает 22% времени запроса. Что вы измените?
serializationrails - 87
После всплеска трафика Puma начинает выбрасывать Errno::EMFILE. Лимит каждого пода равен 1 024 файловым дескрипторам, открыто 400 клиентских сокетов и 500 исходящих сокетов в keep-alive пулах. Что вы сделаете?
problem-solvingdescriptors - 88
Собственный пул Ruby-потоков выполняет работу вне Rails-контроллеров. Один джоб из 20 видит предыдущего tenant в Current.account, создавая утечку данных между клиентами. Как это исправить?
concurrencyrubyrails - 89
Deploy переименовывает InvoiceGenerator в Billing::InvoiceGenerator, пока 420000 queued payloads Sidekiq ссылаются на старый class; retries NameError насыщают Redis. Что вы сделаете?
redisdeploymentdata-structures - 90
Плановый Rails-джоб должен выполняться один раз на клиента среди 40 Sidekiq-процессов. Блокировка Redis имеет TTL 60 с, но некоторые джобы идут 90 с, поэтому два воркера пересекаются и перезаписывают результаты. Что вы измените?
railsbackground-jobsredis - 91
Продукт просит фичу купонов за две недели. Тот же модуль цен Rails вызывает 14 инцидентов в квартал и содержит 2 800 строк callback; безопасное выделение оценивается в шесть недель. Что вы предложите?
estimationincidentscallbacks - 92
Ruby-инженер присылает PR на 900 строк, который добавляет четвёртый ActiveRecord callback для возвратов и содержит только controller specs. Релиз через три дня. Как вы проведёте ревью и менторство?
concurrencycallbacksruby - 93
В code review добавлен rescue StandardError вокруг Sidekiq-джоба выставления счетов с успешным return ради прекращения алертов. В прошлом месяце так молча пропустили 600 счетов. Какой отзыв и замену вы дадите?
feedbackcode-reviewalerting - 94
Изменение junior-инженера после деплоя вызвало 8% ошибок checkout. Он впервые дежурит и хочет сначала найти причину, но выручка падает на $4 000 в минуту. Что вы сделаете?
deploymentrollbackrails - 95
Security support текущей версии Rails заканчивается через четыре месяца. В upgrade 320 deprecation warnings, 18 внутренних gems, а запуск продукта состоится через шесть недель. Как вы выстроите работу?
rails - 96
Набор тестов Rails идёт 48 минут и случайно падает в 7% запусков CI, в основном в спеках часовых поясов и Sidekiq. Команда перезапускает CI до зелёного результата и теряет около 30 инженерных часов в неделю. Что вы измените?
railsbackground-jobstesting - 97
Rails p99 нарушает SLO 800 мс дважды в неделю, но в логах нет request ID, ожидание пула ActiveRecord не измеряется, а трейсы семплируются лишь на 0,1%. У вас пять инженерных дней. Что вы выберете?
slorailsprioritization - 98
В 02:00 успешность платежей падает с 98,8% до 81%, задержка платёжной очереди Sidekiq составляет девять минут, а три недавних деплоя меняли checkout, конфигурацию Redis и клиент провайдера. Как вы поведёте инцидент?
deploymentconfigredis - 99
Senior Ruby-инженер регулярно одобряет запросы, которые проходят тесты, но сканируют 40 миллионов строк в продакшене. Его последний PR добавляет where.not по неиндексированному JSONB-полю в путь с ожидаемыми 600 запросами в секунду. Как вы проведёте ревью?
soft-skillsqueriestesting - 100
3 инцидента за 6 недель произошли из-за неидемпотентных Sidekiq-джобов, но в roadmap нет работы по надёжности, а в понедельник начинается новая фича массовых писем. Какое решение вы предложите команде?
incidentsprioritizationidempotency