Облачные вычисления
Cloud на собеседовании (FAANG)
Amazon Principal Engineers проводят System Design интервью где ожидается: 'Спроектируй Amazon Fulfillment System'. Правильного ответа нет. Оценивается structured thinking, знание trade-offs, умение работать с ограничениями.
- **Amazon SDE3 System Design:** Типичный вопрос - 'Спроектируй систему обработки заказов для Prime Day'. Ожидается: DynamoDB для cart (spiky), SQS для decoupling, Step Functions для workflow, обсуждение RDS vs NoSQL для orders с конкретными аргументами.
- **Google Cloud Senior Engineer:** 'Мигрируй 500TB PostgreSQL в BigQuery без downtime'. Ожидается знание: DMS, Datastream (CDC), Strangler Fig паттерна, Shadow Testing для валидации.
- **Meta Production Engineer:** Troubleshooting сценарий в реальном времени. 'Наш сервис деградирует каждые 4 часа. Что проверишь?' - Structured approach: метрики, логи, паттерн совпадения с cron jobs или Cache TTL.
Design Questions
Cloud System Design интервью в Amazon, Google, Meta проверяют способность проектировать масштабируемые системы. Типичные вопросы: 'Спроектируй Netflix', 'Спроектируй Uber', 'Спроектируй систему URL shortener для 1B пользователей'. Структура ответа: Requirements -> Scale estimation -> API design -> High-level design -> Database design -> Scaling -> Trade-offs. Amazon особенно ценит использование AWS сервисов в ответах.
Estimation framework: DAU (Daily Active Users) -> RPS = DAU * avg_actions / 86400. Storage: RPS * object_size * retention. Bandwidth: RPS * response_size. Затем выбор сервисов под цифры. 10M DAU * 10 actions = ~1157 RPS. Это ECS Fargate с 10-20 инстансами m5.large.
При ответе на Cloud System Design вопрос что делать в первую очередь?
Migration
Cloud Migration вопросы: 'Как мигрировать monolith на AWS без downtime?', 'Как мигрировать 100TB PostgreSQL в RDS?'. Стратегии 6R: Retire (удалить), Retain (оставить on-premise), Rehost (lift & shift), Replatform (небольшие оптимизации), Repurchase (SaaS замена), Refactor/Re-architect (переписать для cloud-native). Большинство enterprise миграций: Rehost -> Replatform поэтапно.
Инструменты: AWS Migration Hub (отслеживание), AWS Application Migration Service (rehost серверов), AWS Database Migration Service (DMS) для гетерогенных миграций (Oracle -> Aurora), AWS Schema Conversion Tool (SCT) для конвертации схем. Big-bang migration vs Strangler Fig Pattern - поэтапная замена модулей.
Strangler Fig Pattern для cloud migration означает:
Troubleshooting
Troubleshooting questions на cloud интервью: 'Lambda функция отвечает медленно - как диагностировать?', 'ECS Task падает через 30 минут - что проверить?', 'S3 запросы неожиданно дорогие - почему?'. Структура ответа: Observe (метрики/логи/трейсы) -> Hypothesize -> Test -> Fix. CloudWatch Logs Insights, X-Ray, Container Insights - основные инструменты.
Типичные проблемы и диагностика: Lambda timeout -> X-Ray чтобы найти медленный downstream. ECS OOM -> CloudWatch Container Insights Memory. S3 дорогой -> Cost Explorer по API операции (GetObject vs ListBucket). RDS high CPU -> Performance Insights top SQL. ALB 5xx -> target group health checks, ECS task logs.
ECS Task неожиданно завершается каждые 30 минут. Первый шаг диагностики:
Tradeoffs
Trade-off вопросы на cloud интервью: 'SQL vs NoSQL?', 'Lambda vs ECS?', 'SQS vs Kinesis?', 'Монолит vs Микросервисы?'. Правильный ответ всегда 'зависит от...' + конкретные критерии выбора. Интервьюер Amazon проверяет: знаешь ли ты ограничения AWS сервисов (не только возможности), принимаешь ли обоснованные решения.
Ключевые trade-offs которые нужно знать: Consistency vs Availability (CAP теорема), Latency vs Throughput (batching), Cost vs Performance (Spot vs On-Demand), Flexibility vs Simplicity (микросервисы vs монолит). DynamoDB: eventual consistency = дешевле и быстрее, strongly consistent = дороже и медленнее.
На вопрос 'Почему был выбран DynamoDB, а не PostgreSQL?' какой ответ демонстрирует senior-level мышление?
Итоги
- **System Design структура:** Requirements (functional + non-functional) -> Scale estimation (DAU -> RPS -> storage) -> API -> High-level -> Database -> Scaling -> Trade-offs. Никогда не начинай рисовать диаграмму без requirements.
- **Migration:** 6R стратегии (Retire/Retain/Rehost/Replatform/Repurchase/Refactor). DMS для database migration с CDC для near-zero downtime cutover. Strangler Fig для поэтапной замены монолита.
- **Troubleshooting:** Observe -> Hypothesize -> Test -> Fix. CloudWatch Logs Insights для паттернов. X-Ray для downstream latency. Performance Insights для SQL. Никогда не меняй конфигурацию без понимания причины.
Связанные темы
Подготовка к cloud интервью объединяет все темы курса:
- AWS Well-Architected Framework — 6 столпов WAF - основа для структурирования ответов на System Design вопросы. 'Security pillar: как обеспечишь безопасность?' - IAM least privilege, VPC, encryption at rest/transit
- Cost Optimization — На senior интервью часто спрашивают 'как сделать это дешевле'. Знание Spot, RI, Savings Plans, Graviton3 и breakeven анализа Lambda vs ECS показывает производственный опыт
- Reliability и DR — Почти каждый System Design вопрос включает 'что если регион упадёт?'. RPO/RTO, Aurora Global DB, Route53 failover - обязательные элементы полного ответа
Вопросы для размышления
- Как подготовить System Design ответ для 'Спроектируй сервис как Stripe' - какие AWS сервисы использовать и какие trade-offs обсудить?
- Как структурировать troubleshooting ответ если тебе дают производственный инцидент (5xx spike) и просят диагностировать за 30 минут?
- Какие реальные production решения из текущего/прошлого проекта можно использовать как примеры trade-off обсуждений на интервью?