Подготовка к собеседованию — Rust-разработчик

Грубые прикидки, которые определят архитектуру. Считайте вслух, округляйте агрессивно.

Что оценить:

• QPS (запросов в секунду): средний и пиковый (пик ≈ 2-3× среднего).
• Объём данных: размер одной записи × число записей × горизонт хранения.
• Соотношение чтение/запись (read:write) — определяет, нужны ли реплики чтения и кэш.
• Пропускная способность (bandwidth): QPS × размер ответа.
• Хранилище (storage): рост в год.

Полезные числа для счёта в уме:

Величина	Значение
Секунд в сутки	~86 400 ≈ 10⁵
Месяц	~2.5 млн сек
1M запросов/сутки	≈ 12 QPS в среднем
1B запросов/сутки	≈ 12 000 QPS

Пример расчёта (URL shortener): 100M новых ссылок/мес → 100M / 2.5M сек ≈ 40 записей/сек. Read:write = 100:1 → 4000 чтений/сек. Размер записи ~500 байт → 100M × 500B = 50 ГБ/мес → 600 ГБ/год → за 10 лет ~6 ТБ.

💡 Вывод из чисел сразу формулируйте: «40 записей/сек — это легко для одной БД. 4000 чтений/сек — добавим кэш и реплики чтения».

Опишите контракт сервиса — это фиксирует функциональность и помогает интервьюеру понять модель. REST/gRPC, основные эндпоинты:

POST /api/v1/urls           {long_url, custom_alias?, ttl?} -> {short_url}
GET  /{short_key}           -> 301/302 redirect

Проговорите: методы, параметры, идемпотентность (POST идемпотентен?), пагинацию для списков (cursor-based, не offset на больших данных), авторизацию (api_key / токен).

• Опишите ключевые сущности и связи (таблицы / коллекции).
• Выберите тип БД и обоснуйте:
  • SQL (Postgres, MySQL): сложные связи, транзакции, строгая консистентность, аналитические запросы, JOIN. Берите по умолчанию, если нет причины не брать.
  • NoSQL key-value / wide-column (DynamoDB, Cassandra): огромный масштаб записи, простой паттерн доступа по ключу, горизонтальное шардирование «из коробки», eventual consistency.
  • Документная (MongoDB): гибкая схема, вложенные документы.
  • In-memory (Redis): кэш, счётчики, rate limiting, очереди, leaderboard.
• Сразу подумайте о ключе шардирования (по чему партиционируем).

Опишите словами (или схемой) компоненты и поток запроса:

[Client] -> [DNS] -> [Load Balancer] -> [API / App Servers (stateless)]
                                              |-> [Cache (Redis)]
                                              |-> [Database (+ read replicas)]
                                              |-> [Message Queue] -> [Workers]
                                         [CDN] -> [Blob Storage (S3)]

Проведите типичный запрос по этому пути от клиента до БД и обратно.

• LB распределяет трафик между инстансами (round-robin, least-connections, consistent hashing). Даёт горизонтальное масштабирование и отказоустойчивость (убирает мёртвые ноды через health checks).
• L4 (TCP) — быстрее; L7 (HTTP) — умеет роутинг по URL/заголовкам, TLS-терминацию.
• Reverse proxy (Nginx, Envoy): TLS-терминация, сжатие, кэш, защита бэкенда, единая точка входа.
• 💡 Приложения держите stateless — тогда LB может слать запрос на любой инстанс. Сессии — в Redis, не в памяти процесса.