System Design Interview — один из самых сложных этапов технического собеседования в международных компаниях. Здесь мало знать правильный ответ: нужно думать вслух на английском, структурировать рассуждение в реальном времени и убедительно аргументировать архитектурные решения перед интервьюером.

Эта статья — практический гайд для разработчиков, которые готовятся к System Design Interview на английском. Вы получите фреймворк из 6 шагов, готовые фразы для каждого этапа, технический словарь из 50+ терминов и разбор трёх типичных вопросов с образцами ответов. Для общего понимания того, как устроено IT-собеседование на английском, рекомендуем начать с нашего гайда по полному процессу — от резюме до оффера.

Зачем System Design Interview важен для международных компаний

В крупных технологических компаниях — Google, Amazon, Meta, Microsoft, Uber, Airbnb и сотнях других — System Design Interview является обязательным этапом для Middle и Senior позиций. Причина простая: компании строят системы, которые обслуживают миллионы или миллиарды пользователей, и им нужны инженеры, способные принимать взвешенные архитектурные решения.

В отличие от алгоритмических задач, System Design не имеет единственно правильного ответа. Интервьюер оценивает:

  • умение задавать правильные уточняющие вопросы перед проектированием;
  • способность оценивать масштаб системы на основе числовых данных;
  • понимание компромиссов между разными архитектурными подходами;
  • навык объяснять технические решения ясно и структурировано.

Последний пункт — особый вызов для русскоязычных разработчиков. Техническая экспертиза может быть высокой, но если рассуждение на английском выглядит неструктурированным или кандидат не знает, как назвать компонент, это снижает оценку. Именно поэтому фреймворк и терминология важны так же, как знание архитектурных паттернов.

Фреймворк ответа: 6 шагов от вопроса до решения

Ниже — универсальная структура, которую можно применять к любому System Design вопросу. Она принята как неофициальный стандарт в большинстве крупных компаний и хорошо знакома интервьюерам. Следование этой структуре само по себе демонстрирует зрелость инженера.

Шаг 1. Clarify requirements (Уточнение требований)

Никогда не начинайте проектировать сразу. Первые 3–5 минут — уточнение: что именно нужно спроектировать, какие функции обязательны, какие — в рамках scope данного интервью. Это демонстрирует инженерную зрелость и предотвращает трату времени на неверные предположения.

Шаг 2. Estimate scale (Оценка масштаба)

Capacity estimation — расчёт нагрузки: сколько пользователей, сколько запросов в секунду, какой объём данных за год. Цифры не обязаны быть точными — важна логика вычислений. Этот шаг показывает, умеете ли вы принимать решения на основе данных, а не интуиции.

Шаг 3. High-level design (Высокоуровневая архитектура)

Нарисуйте общую схему системы: основные компоненты и связи между ними. Обычно это клиент, API gateway, сервисы, базы данных, очереди сообщений, CDN. На этом этапе — широко, без деталей реализации.

Шаг 4. Deep dive (Детальный разбор компонентов)

Интервьюер, как правило, сам направляет: «Let's dive deeper into the database layer» или «How would you handle the write path?». Ваша задача — детально разобрать выбранный компонент: схему данных, алгоритм, масштабирование, обработку сбоев.

Шаг 5. Discuss trade-offs (Обоснование выбора)

Каждое решение имеет компромиссы. Почему SQL, а не NoSQL? Почему push, а не pull? Почему eventual consistency, а не strong consistency? Артикулированное обсуждение trade-offs — признак Senior-инженера.

Шаг 6. Summarize (Итог)

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

Ключевые фразы для каждого этапа

Готовые формулировки снижают когнитивную нагрузку на интервью: вы тратите ресурсы на мышление, а не на подбор слов. Заучите эти фразы до автоматизма — это то, что тренирует LingoChat в формате технического mock-интервью.

Уточнение требований

Цель фразы Фраза на английском
Уточнить функциональность «Before I start, let me clarify some requirements. Should the system support X?»
Определить scope «For the scope of this interview, can we assume we're focusing on the core features only?»
Уточнить пользователей «Who are the primary users? Are we targeting consumers, businesses, or both?»
Уточнить ограничения «Are there any specific latency or availability requirements I should design for?»
Подтвердить понимание «So to summarize the requirements: we need X, Y, and Z. Does that sound right?»
Исключить из scope «I'll leave authentication and billing out of scope for now — is that okay?»

Оценка масштаба (capacity estimation)

Цель фразы Фраза на английском
Начать расчёты «Let me do a quick back-of-the-envelope calculation.»
Допущение о пользователях «Let's assume we have 10 million daily active users.»
Вычислить RPS «That gives us roughly 100 requests per second on average, with peaks up to 500 RPS.»
Оценить хранилище «If each user generates about 1 KB of data per day, we're looking at 10 GB per day, or around 3.5 TB per year.»
Уточнить допущение «I'm assuming a read-to-write ratio of 10:1 — is that a reasonable assumption?»

Высокоуровневая архитектура

Цель фразы Фраза на английском
Начать рисовать схему «Let me start with a high-level diagram and then we can drill down into specific components.»
Описать компонент «At the top we have the client — mobile and web. Requests go through an API gateway, which handles routing and rate limiting.»
Описать поток данных «The write path looks like this: the client sends a request, the API gateway forwards it to the service, which writes to the primary database and publishes an event to the message queue.»
Выделить ключевые решения «The key design decisions here are the choice of database and how we handle caching.»

Trade-offs и обоснование выбора

Цель фразы Фраза на английском
Ввести trade-off «There's a trade-off here between consistency and availability.»
Объяснить выбор «I'm choosing a NoSQL database here because the data is schemaless and we need horizontal scalability.»
Признать ограничения «The downside of this approach is that we lose strong consistency, but for this use case eventual consistency is acceptable.»
Сравнить варианты «We could use a push model or a pull model here. Push gives lower latency, but pull is easier to scale and more resilient to consumer failures.»
Обозначить альтернативу «An alternative approach would be to use a CDN for this, which would significantly reduce latency for read-heavy workloads.»
Объяснить решение «Given our read-heavy access pattern and the need for low latency, I'd go with Redis as the caching layer.»

Технический словарь для System Design

Ниже — 50+ терминов, которые регулярно встречаются на System Design Interview. Для каждого — краткое определение и пример использования в речи. Это тот минимум, который нужно знать до интервью. Стратегию изучения технической терминологии — как встраивать её в активный словарь — разбираем в статье про английский для разработчика.

Масштабирование и производительность

Термин Определение и пример использования
Horizontal scaling Добавление новых серверов вместо усиления существующих. «We can handle the increased load by horizontal scaling — adding more application servers behind the load balancer.»
Vertical scaling Увеличение мощности существующего сервера. «Vertical scaling has limits — at some point we'll hit the ceiling of a single machine.»
Load balancer Распределитель входящего трафика между серверами. «The load balancer distributes incoming requests across multiple application servers using round-robin.»
Throughput Количество операций, обрабатываемых системой за единицу времени. «Our target throughput is 10,000 writes per second.»
Latency Время ответа системы. «We need p99 latency under 100 milliseconds for the search endpoint.»
Bottleneck Узкое место, ограничивающее производительность системы. «The database is the bottleneck here — we need to add a caching layer.»
Rate limiting Ограничение частоты запросов от клиента. «We apply rate limiting at the API gateway: 1,000 requests per minute per user.»
Caching Хранение часто запрашиваемых данных в быстром хранилище. «We cache the top 1% of most-requested content in Redis with a TTL of 5 minutes.»
CDN (Content Delivery Network) Сеть серверов для доставки статического контента ближе к пользователям. «Static assets are served from the CDN to reduce latency for users in different regions.»
Back-of-the-envelope calculation Быстрая грубая оценка без точных данных. «Let me do a back-of-the-envelope calculation to estimate storage requirements.»

Базы данных и хранилище

Термин Определение и пример использования
Sharding Горизонтальное разделение базы данных на части (шарды). «We shard the user table by user_id using consistent hashing.»
Replication Копирование данных на несколько серверов для надёжности. «We use primary-replica replication: writes go to the primary, reads are distributed across replicas.»
Consistent hashing Алгоритм распределения данных по узлам, минимизирующий перераспределение при изменении кластера. «Consistent hashing ensures that adding a new cache node only remaps a fraction of the keys.»
SQL vs NoSQL Реляционные vs нереляционные базы данных. «For structured, relational data with complex queries I'd use SQL; for schemaless, high-volume writes — NoSQL.»
ACID Свойства транзакций: Atomicity, Consistency, Isolation, Durability. «For financial transactions we need ACID guarantees — that rules out eventual consistency.»
CAP theorem Теорема о невозможности одновременно обеспечить consistency, availability и partition tolerance. «Given the CAP theorem, we're choosing availability over strong consistency for this use case.»
Eventual consistency Гарантия, что все реплики в итоге придут к одному значению, но не мгновенно. «Eventual consistency is acceptable for the news feed — users can tolerate a slight delay in seeing new posts.»
Strong consistency Гарантия, что все читатели видят последнюю запись немедленно. «For inventory management we need strong consistency — a product shouldn't appear available after it's sold.»
Write-through / Write-back cache Стратегии записи в кэш. «Write-through ensures data is immediately persisted to the database, at the cost of higher write latency.»
Time-series database База данных, оптимизированная для хранения данных с временными метками. «For metrics and monitoring data, a time-series database like InfluxDB is a better fit.»

Архитектурные паттерны

Термин Определение и пример использования
Microservices Архитектура из независимых сервисов с отдельным деплоем. «Breaking the monolith into microservices allows teams to deploy independently.»
Message queue Очередь для асинхронной передачи сообщений между компонентами. «We use a message queue to decouple the upload service from the video processing pipeline.»
Event-driven architecture Архитектура, в которой компоненты общаются через события. «An event-driven architecture lets us add new consumers without modifying the producer.»
API gateway Единая точка входа для всех клиентских запросов. «The API gateway handles authentication, rate limiting, and routing to downstream services.»
Circuit breaker Паттерн для предотвращения каскадных сбоев. «The circuit breaker trips after 5 consecutive failures and stops forwarding requests to the unhealthy service.»
Pub/Sub Паттерн «издатель — подписчик» для асинхронного обмена сообщениями. «We use pub/sub to fan out notifications: the order service publishes an event, and both the email and push notification services consume it.»
CQRS (Command Query Responsibility Segregation) Разделение операций записи и чтения на отдельные модели. «With CQRS, write operations go to the command model and reads come from a separately optimised read model.»
Event sourcing Хранение состояния системы как последовательности событий. «Event sourcing gives us a complete audit trail and the ability to replay events to reconstruct state.»
Service mesh Инфраструктурный слой для управления взаимодействием между сервисами. «A service mesh like Istio handles load balancing, retries, and observability between microservices.»
Saga pattern Паттерн управления распределёнными транзакциями через последовательность локальных транзакций. «For the checkout flow we use the saga pattern to coordinate payment, inventory reservation, and order creation across three services.»

Доступность и надёжность

Термин Определение и пример использования
High availability (HA) Способность системы работать без перерывов. «We target 99.99% availability — that's less than 1 hour of downtime per year.»
Fault tolerance Способность продолжать работу при отказе компонентов. «The system is fault tolerant — if one availability zone goes down, traffic automatically shifts to the remaining zones.»
SLA / SLO / SLI Service Level Agreement / Objective / Indicator — соглашения об уровне обслуживания. «Our SLO for the search service is p99 latency under 200ms, measured by the SLI from our APM tool.»
Redundancy Дублирование компонентов для обеспечения надёжности. «We deploy across three availability zones for redundancy.»
Failover Автоматическое переключение на резервную систему при сбое. «The database has automatic failover — if the primary goes down, a replica is promoted within 30 seconds.»
Idempotency Свойство операции: повторное выполнение не меняет результата. «The payment endpoint must be idempotent — if the client retries due to a network timeout, we shouldn't charge twice.»
Heartbeat Периодический сигнал о работоспособности узла. «Each worker sends a heartbeat every 10 seconds; if we miss three consecutive heartbeats, we mark it as dead.»

Realtime и коммуникационные протоколы

Термин Определение и пример использования
WebSocket Протокол двунаправленной связи в реальном времени. «For live chat we use WebSocket connections to push messages to clients without polling.»
Long polling Клиент держит соединение открытым, ожидая ответа от сервера. «Long polling is simpler than WebSocket but adds more overhead — each poll is a new HTTP request.»
Server-Sent Events (SSE) Механизм однонаправленного потока событий от сервера к клиенту. «For live score updates SSE is sufficient — we only need server-to-client communication.»
gRPC Высокопроизводительный протокол RPC от Google на базе Protocol Buffers. «For internal service-to-service communication we use gRPC — it's faster and more efficient than REST.»
Fan-out Рассылка сообщения или события множеству получателей. «When a user posts, we fan out the post to the feeds of all their followers.»
Pull vs Push Клиент сам запрашивает данные vs сервер отправляет данные клиенту. «For the news feed we use a push model for users with few followers and a pull model for celebrities — this is the hybrid approach Twitter uses.»

Разбор 3 типичных вопросов

Ниже — три классических System Design вопроса с образцами ответов по фреймворку. Используйте их как шаблон, который вы адаптируете под реальные вопросы. О том, как строить ответы на behavioral-вопросы на том же интервью, читайте в нашем разборе метода STAR для IT-собеседования.

1. Design a URL shortener (как bit.ly)

Clarify: «Let me start with a few clarifying questions. Should the system support custom aliases, or only auto-generated short URLs? Do we need analytics — click counts, geographic breakdown? What's the expected scale?»

Estimate: «Assuming 100 million URLs created per day and a 10:1 read-to-write ratio, we have about 1 billion redirects per day — roughly 12,000 redirects per second. Each URL record is maybe 500 bytes, so about 50 GB of new data per day.»

High-level: «The core components are: a write service that generates short codes and stores the mapping in a database, a redirect service that looks up the original URL and returns a 301 or 302 redirect, and a cache layer in front of the database for hot URLs.»

Deep dive: «For the short code generation, I'd use base-62 encoding of an auto-incrementing ID — that gives us 62^7 ≈ 3.5 trillion possible URLs. For the database, a key-value store like DynamoDB is a good fit: the access pattern is simple key lookups, and we need horizontal scalability.»

Trade-offs: «Using a 301 redirect is better for performance — browsers cache it, reducing future load on our servers. But if we need accurate analytics, a 302 is necessary because browsers won't cache it and each visit goes through our system.»

2. Design a messaging system (как WhatsApp)

Clarify: «Are we designing one-on-one messaging, group chats, or both? Do we need to support read receipts, message delivery status, and media files? What's our target scale — how many daily active users?»

Estimate: «With 500 million DAU sending an average of 40 messages per day, that's 20 billion messages per day — about 230,000 messages per second. A message with metadata is roughly 1 KB, so about 20 TB of message data per day.»

High-level: «The system needs: a chat service that handles message routing, a connection service that manages WebSocket connections for online users, a message storage layer, and a notification service for offline users.»

Deep dive: «For message delivery I'd use a combination of WebSocket for online users and push notifications for offline users. Messages are stored in a NoSQL database — Cassandra is a good fit here because it's optimised for high write throughput and time-series access patterns. We partition by conversation_id to keep messages for a single conversation on the same node.»

Trade-offs: «Storing all messages forever is expensive. We could apply a tiered storage strategy: hot messages in Cassandra, messages older than 90 days in cheaper object storage like S3. The trade-off is slightly higher read latency for old messages.»

3. Design a video streaming service (как YouTube)

Clarify: «Should we design the full system including upload, transcoding, and streaming? Are we focusing on one particular region or globally distributed? Do we need support for live streaming or only on-demand?»

Estimate: «With 2 billion users and 500 hours of video uploaded per minute, assuming average video size after transcoding is 500 MB, we're storing about 15 TB of new video data per day. For streaming: if 10 million users are watching concurrently at 5 Mbps average bitrate, we need about 50 Tbps of bandwidth — this is why CDN is non-negotiable.»

High-level: «The write path: user uploads a raw video → it's stored in object storage → a transcoding service converts it into multiple resolutions (360p, 720p, 1080p, 4K) → transcoded files are distributed to CDN edge nodes. The read path: user requests a video → DNS routes to the nearest CDN edge → if miss, CDN fetches from origin storage.»

Deep dive: «For transcoding, I'd use a message queue to decouple upload from processing. When a video is uploaded, the upload service publishes an event to the queue. Worker nodes pick up jobs and run FFmpeg for transcoding. This is horizontally scalable — we can add workers during peak load.»

Trade-offs: «Adaptive bitrate streaming (HLS or DASH) is essential for good user experience — it adjusts quality based on network conditions. The trade-off is increased storage cost since we store the same video in multiple resolutions, but the improvement in user experience justifies it.»

Как тренироваться в одиночку и с партнёром

System Design Interview требует практики устной речи под давлением — написание конспектов здесь не помогает. Нужно тренировать именно рассуждение вслух на английском с сохранением структуры.

Тренировка в одиночку

  1. «Объясни себе». Возьмите любой классический вопрос (Design Twitter, Design Dropbox, Design Uber) и проговорите решение вслух, следуя шагам фреймворка. Засекайте время: на весь ответ — 30–40 минут.
  2. Запись и разбор. Запишите ответ на видео или аудио. При прослушивании отмечайте: где вы теряете структуру, где не хватает терминологии, где слишком длинные паузы.
  3. AI-собеседник. LingoChat поддерживает формат технического mock-интервью: задаёт вопросы по System Design, задаёт уточняющие вопросы как настоящий интервьюер и разбирает языковые ошибки. Это снижает порог входа перед практикой с живым партнёром.
  4. Систематизация терминологии. Пройдитесь по словарю выше и для каждого термина составьте одно предложение из вашего реального опыта. Это переводит термин из пассивного словаря в активный.

Тренировка с партнёром

Парная практика эффективнее одиночной, потому что живой интервьюер задаёт follow-up вопросы, которые трудно предсказать. Найти партнёра можно на платформах вроде Pramp, interviewing.io или в Telegram-сообществах по подготовке к FAANG.

Договоритесь о роли: один — кандидат, другой — интервьюер. Интервьюер должен активно перебивать: «Wait, how would you handle the case when…», «What if the cache goes down?», «Can you elaborate on the database choice?». Именно эти неожиданные вопросы тренируют самое важное — гибкость мышления на английском. О том, как системно выстраивать разговорную практику, рассказываем в материале про форматы разговорного английского онлайн.

Методика коротких ежедневных сессий вместо редких марафонов — в статье про микро-привычку 5 минут в день. Тот же принцип работает для подготовки к интервью: ежедневные 15–20 минут устной практики за 4 недели дают больше, чем два «забега» за выходные перед собеседованием.

Типичные ошибки русскоязычных на System Design

Большинство ошибок — структурные и коммуникационные, а не технические. Вот самые распространённые.

Сразу прыгать в детали

Самая частая ошибка — начинать проектировать базу данных, не уточнив требования. Интервьюер оценивает умение задавать правильные вопросы так же высоко, как и техническое решение. Первые 5 минут всегда — Clarify.

Не думать вслух

Русскоязычные разработчики часто привыкли сначала всё обдумать внутри, потом выдать ответ. На System Design Interview это воспринимается как молчание. Интервьюер не знает, что происходит у вас в голове. Озвучивайте рассуждение: «I'm thinking about the trade-offs here. On one hand… on the other hand…»

Игнорировать масштаб

Решение, которое работает для 1 000 пользователей, часто не работает для 100 миллионов. Capacity estimation — это не формальность: она определяет выбор базы данных, нужен ли шардинг, какого размера кэш. Если вы пропускаете этот шаг, интервьюер не получает сигнала о вашем умении думать в масштабе.

Нет обсуждения trade-offs

Называть компоненты без объяснения, почему именно они, — слабая позиция. «I would use Kafka here» без объяснения, почему не RabbitMQ или SQS, — это пропущенный сигнал. Каждый выбор должен сопровождаться обоснованием и признанием ограничений.

Языковые паузы в ключевых моментах

Долгий поиск слов во время объяснения trade-offs или deep dive разрушает впечатление от технически правильного ответа. Решение — заучить ключевые фразы из таблиц выше до автоматизма. Это освобождает когнитивный ресурс для содержательного мышления. Системный подход к работе с повторяющимися языковыми ошибками описан в статье как избавиться от ошибок в английском.

Не резюмировать в конце

Многие заканчивают ответ на полуслове — когда закончилось время. Если осталась минута, используйте её для краткого Summary: «So, to summarize: we designed a system that handles X, using Y for storage and Z for caching. The key trade-offs were…» Это оставляет у интервьюера ощущение завершённости.

Итог

System Design Interview на английском — это навык, который отрабатывается практикой, а не просто чтением гайдов. Фреймворк из 6 шагов даёт структуру, технический словарь — язык, образцы ответов — ориентиры. Но всё это работает только в связке с устной практикой.

Начните с трёх шагов: выучите фразы для Clarify и Trade-offs — они нужны на любом вопросе. Затем разберите 5–7 классических вопросов по фреймворку письменно. Потом переходите к устной практике — с таймером, записью или AI-собеседником.

Для общей подготовки к IT-собеседованию на английском — наш полный гайд от резюме до оффера. Для параллельной работы над разговорным навыком — статья про daily standup на английском: те же принципы технической коммуникации, но в контексте ежедневной командной работы. А если вы хотите оценить, на каком уровне ваш английский сейчас, — начните с понимания шкалы A1–C2 и реалистичных сроков достижения нужного уровня.

Также рекомендуем статью code review на английском — навык письменной технической коммуникации, который часто проверяется на том же интервью через take-home задания и обсуждение архитектурных решений в PR.