Как устроен системный дизайн в Stripe: гид по интервью

Введение

В большинстве IT-гигантов вас просят «спроектировать Twitter» или «придумать систему обмена сообщениями для миллиарда пользователей». В Stripe — нет. Там дают задачу, которая звучит как реальный рабочий день в платежной компании, и смотрят, как вы выкручиваетесь.

Кандидаты описывают это одинаково: «меньше абстрактного дизайна, больше стены контекста про платежную инфраструктуру — найди реальную проблему и построй что-то, что не развалится». Один инженер недавно сказал прямо: «Это был не набор чистых вопросов, а задача про Stripe, где главный тест — как ты извлечешь проблему из вороха слов».

Этот раунд вознаграждает тех, кто умеет проектировать точные API и модели данных, размышлять об отказах и масштабировании в системах, которые двигают деньги, и не останавливается на схеме, а продумывает развертывание и эксплуатацию.

В этом гиде — только системный дизайн в Stripe: его место в процессе, критерии оценки, реальные вопросы и стратегия подготовки. Кодинг, поведенческие интервью и скрининг с рекрутером остаются за рамками.

Топ-5 самых частых вопросов (с указанием, где встречаются)

1. Спроектируйте сервис учёта (ledger / bookkeeping). (Stripe, классика) — Визитная карточка Stripe. Открытая задача, проверяющая, как вы моделируете движение денег, гарантируете корректность и строите пути чтения и записи.
2. Спроектируйте API для хранения транзакций и журнала операций. (продуктовые команды Stripe) — Более узкая, API-ориентированная версия предыдущей. Часто встречается в продуктовых командах, где интерфейс — главное.
3. Редизайн внутренней системы авторизации. (инфраструктурные команды) — Дано количество сервисов и целевой RPS. Спроектируйте схему, которую можно раскатить по всей инфраструктуре. Оценивается умение разделить управление политиками и быструю проверку прав.
4. Спроектируйте ограничитель частоты запросов (rate limiter). (Stripe, Amazon, Google) — Счетчики, общее состояние и поведение под нагрузкой.
5. Спроектируйте сервис метрик. (платформенные команды) — Пропускная способность, хранение временных рядов, чистый API запросов, компромиссы между скоростью приема данных и агрегацией.

Как проходит интервью

Stripe известна компактным процессом: вместо 6 раундов, как во многих гигантах, здесь обычно около 4. При этом уровень Staff в Stripe соответствует тому, что в других компаниях называют M1 или «старший+».

Такая сжатость означает, что каждый раунд имеет больший вес, и системный дизайн — один из ключевых.

• Для мидлов и выше — отдельный раунд 45–60 минут.
• Для сеньоров — иногда добавляют второе архитектурное интервью или выделенный раунд по проектированию API.
• Для инженерных менеджеров — 1–2 дизайн-интервью плюс проектная презентация, раунд про опыт и цели, а также стратегию и исполнение.
• Для джуниоров и выпускников — отдельного раунда по дизайну обычно нет. Вместо этого дизайнерское мышление проверяют в интеграционном раунде, где нужно собрать фичу поверх реального репозитория.

Вместо физической доски вы обычно рисуете схемы в Whimsical. Задача почти всегда связана с тем, что Stripe действительно строит. Интервьюеры проводят структурированную сессию: четкий промпт, пошаговое усложнение и оценка по 4–5 измерениям.

Особенность: сильные кандидаты тратят первые минуты на уточнение ограничений, переформулирование реальной проблемы и четкое обозначение того, что не входит в задачу. Один из интервьюеров использует редизайн внутренней системы авторизации: «вот количество сервисов и RPS — спроектируйте схему, которую можно раскатить по всей инфраструктуре». Другой — задачу по шардированию платформы данных, взятую из реальной системы.

Ощущение ближе к дизайн-ревью со старшим коллегой, чем к викторине.

Что оценивают (и на что смотрят в первую очередь)

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

1. Формулировка проблемы (Problem Framing)

Умение превратить нечеткий, многословный промпт в четкую постановку задачи. Это первый фильтр, и здесь проваливается большинство кандидатов. Интервьюеры могут мягко направить вас, но они запомнят, понадобилась ли вам подсказка.

2. Проектирование API и моделей данных

API Stripe — это предмет гордости компании: простые в использовании и сложные для неправильного применения. Они ждут такого же инстинкта от вас. Даже в архитектурной задаче вас могут попросить спроектировать API для хранения транзакций или журнала операций.

3. Отказоустойчивость и масштабирование

Где ваша система сломается первой? Ценятся кандидаты, которые точно определяют узкие места, размышляют о глобальной репликации и региональности, а также знают, где разместить кеш для низкой задержки. Проект с одной базой в одном регионе — красный флаг.

4. Разделение ответственности (Separation of Concerns)

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

5. Выход за рамки схемы (Delivery)

Для уровня Staff ответ не заканчивается архитектурой. Развертывание, тестирование, мониторинг и согласование между командами — часть ответа, а не «дополнительный бонус». Как сказал один интервьюер: «Технический дизайн часто не самое сложное; сложное — заставить его работать в продакшене».

Чем Stripe отличается от FAANG

Главное отличие — привязка к реальному домену. Классический вопрос Stripe («спроектируйте сервис учёта») задают годами именно потому, что нет единственно правильного ответа.

Также могут попросить:

• смоделировать транзакции,
• спроектировать пайплайн метрик,
• переработать внутренний слой авторизации.

Это не абстракции на доске — это задачи, которые Stripe реально решала.

API-дизайн — красная нить. Интервьюеры будут глубоко копать ваши интерфейсы и модели данных. Будьте готовы защищать, почему эндпоинт выглядит именно так, и как его можно использовать неправильно.

В продуктовых командах дизайн API и опыт разработчика (DX) часто важнее, чем просто «сырые» цифры масштаба.

Полный список вопросов (категории)

Платежный домен

• Спроектируйте сервис учёта (ledger).
• Спроектируйте API для хранения транзакций и журнала операций.
• Смоделируйте движение денег между счетами с гарантией корректности.

Инфраструктура и надежность

• Спроектируйте ограничитель частоты запросов (rate limiter).
• Спроектируйте сервис метрик (time-series + query API).
• Спроектируйте распределенный LRU-кеш.
• Спроектируйте систему мониторинга производительности приложений (APM).

Безопасность и авторизация

• Редизайн внутренней системы авторизации (fast path + policy management).
• Спроектируйте систему ролей и прав для микросервисной архитектуры.

Общие (но тоже встречаются)

• Спроектируйте Instagram.
• Спроектируйте Ticketmaster.

Как подготовиться: стратегия

• Тренируйте проектирование API и моделей данных. Это самый важный навык. Учитесь защищать свой интерфейс, а не просто рисовать его.
• Изучите платёжную сферу. Разберитесь, как устроены ledgers, транзакции и как система, работающая с деньгами, остаётся корректной.
• Регулярно тренируйтесь извлекать требования. Берите многословный промпт и переформулируйте суть в двух предложениях, прежде чем начинать проектировать.
• Оттачивайте навыки масштабирования и надежности. Учитесь определять узкие места, добавлять репликацию по регионам и осознанно размещать кеш.
• Не останавливайтесь на схеме. Всегда завершайте ответ этапом развертывания, тестирования, мониторинга и взаимодействия с командами.
• Проводите замеры по таймеру. Раунд идет быстро — тренируйтесь под давлением времени с помощью мок-интервью.

Типичные ошибки

• Сразу бросаться к решению. Начать проектировать без уточнения задачи — самый частый способ провалиться.
• Относиться как к абстрактной доске. Игнорирование API и «размывание» модели данных убивает баллы.
• Мыслить одной базой в одном регионе. Без учета репликации и региональности вы рискуете показаться неопытным.
• Смешивать разные задачи в одном компоненте. Разделяйте быстрый и медленный пути, прием и запросы — иначе система становится неудобоваримой.
• Заканчивать на архитектуре. Пропуск развертывания, мониторинга и тестирования не даст вам пройти барьер Staff.

Часто задаваемые вопросы

Сколько длится интервью по системному дизайну?

Для мидлов и выше — 45–60 минут. Для сеньоров может быть два раунда (архитектура + API).

Какие вопросы задают?

Сервис учёта, API транзакций, rate limiter, сервис метрик, распределенный LRU-кеш, APM-система. Многие из них прямо связаны с платежной сферой.

Чем отличается от Google или Meta?

Задачи привязаны к реальной инфраструктуре Stripe, а акцент на API и моделях данных сильнее, чем в Google/Meta, где чаще проверяют абстрактные «масштабные» головоломки.

Нужно ли писать код?

Нет. Код пишут в отдельных раундах (практика и интеграция), но не в дизайне.

Отличается ли интервью по уровням?

Да. У джуниоров отдельного раунда нет; у мидлов — один; у сеньоров может быть два; у менеджеров — один-два плюс проектная презентация.

Можно ли пройти, если я работал в маленькой компании?

Да, если вы показываете глубокое понимание своих прошлых проектов и ясно рассуждаете о компромиссах. Интервьюерам важнее образ мыслей, чем абсолютный масштаб.

Какой инструмент для схем используется?

Обычно Whimsical вместо физической доски. Освойтесь с цифровым рисованием схем.

Резюме

Собеседование по системному дизайну в Stripe — это не абстрактная задача, а проверка вашей способности работать с нечеткими требованиями в высоконагруженной платежной среде. Успех приносят: четкая формулировка проблемы, сильный API-дизайн, продуманная отказоустойчивость, разделение ответственности и умение довести дизайн до продакшена.

Материал подготовлен на основе отзывов инженеров Stripe и кандидатов, прошедших собеседование.