Senior System Design Mock Interview: Design an e-commerce platform

Ось структурований конспект українською мовою на основі наданого відео.

1. Назва відео:
Проектування вебсайту електронної комерції (E-commerce Website Design)

2. Ключова тема:
Системний дизайн (System Design)

3. Мета відео:
Розробити високорівневу архітектуру для вебсайту електронної комерції, яка охоплює три ключові функції: пошук товарів, додавання товарів у кошик з механізмом резервування (щоб уникнути overselling) та сповіщення користувачів про зміну цін. Відео демонструє реальний процес співбесіди, де кандидат проходить через збір вимог, визначення нефункціональних вимог, проектування API, сутностей та високорівневої архітектури, а потім отримує детальний фідбек від інтерв'юера.

4. Основні концепції/кроки:

• Збір вимог та визначення нефункціональних вимог (Non-Functional Requirements): Інтерв'юер та кандидат спільно визначають три основні функції: пошук, додавання до кошика з резервуванням (10-хвилинний TTL) та сповіщення про зміну цін. Для кожної функції визначаються нефункціональні вимоги: для пошуку — низька затримка та доступність; для кошика та оформлення замовлення — узгодженість (consistency) та відмовостійкість; для сповіщень — доступність та відносно низька затримка.
• Проектування API та сутностей (Entities): Кандидат пропонує прості RESTful API для кожної функції (наприклад, GET /store/search?keyword=..., POST /store/add-to-cart, POST /store/checkout, POST /store/subscribe). Він визначає основні сутності: Item (з полями item_id, quantity, version_id для оптимістичного блокування), Cart (з user_id, cart_id, state), CartItems (з cart_id, item_id, quantity) та Subscription (з user_id, item_id).
• Високорівневий дизайн (High-Level Design) з використанням Redis для резервування: Кандидат пропонує використовувати Redis як in-memory сховище для "м'якого резервування" (soft reservation) товарів у кошику. Коли користувач додає товар, у Redis створюється запис з TTL 10 хвилин, який зменшує доступну кількість. Якщо TTL спливає, кількість автоматично повертається. Це запобігає overselling, дозволяючи лише одному користувачеві "зарезервувати" останній екземпляр товару. Для пошуку пропонується використовувати Elasticsearch.
• Обробка сповіщень про зміну цін (Price Change Notifications): Для відстеження змін цін у базі даних інтерв'юер пропонує використати Change Data Capture (CDC). Кандидат проектує асинхронний пайплайн: CDC-подія потрапляє в чергу (queue), звідки її забирає worker. Worker знаходить усіх підписаних користувачів з таблиці Subscription та кладе завдання на сповіщення в іншу чергу. Для реального часу (наприклад, банер на сайті) пропонується використати Server-Sent Events (SSE) як більш легку альтернативу WebSocket, яка дозволяє серверу "підписати" клієнта на оновлення конкретного товару.
• Обговорення альтернатив та компромісів (Trade-offs): Інтерв'юер наголошує на важливості обговорення альтернативних рішень. Наприклад, замість Redis для резервування можна було б використати оптимістичне блокування (optimistic concurrency control) в самій базі даних (PostgreSQL) разом з cron job для очищення прострочених кошиків. Кандидат також обговорює вибір між SQL та NoSQL, де інтерв'юер пояснює, що вибір залежить не стільки від об'єму даних, скільки від наявності чітких зв'язків між сутностями (тоді краще SQL) та потреби в гнучкості схеми (тоді NoSQL).
• Аналіз відмов та спостережуваність (Failure Scenarios & Observability): Кандидат обговорює потенційні точки відмови, такі як падіння Redis (вирішується через персистентність даних у таблиці CartItems) або payment provider. Для моніторингу затримки сповіщень пропонується логувати часові мітки на кожному етапі (CDC отримано, додано в чергу, worker отримав) та відстежувати розмір черги, використовуючи централізовану систему метрик (як Monarch у Google).

5. Висновки/Headline:
Успішний системний дизайн на співбесіді вимагає не просто побудови рішення, а глибокого занурення в ключові проблеми (concurrency, real-time updates), обговорення компромісів між різними підходами (Redis vs. OCC, WebSocket vs. SSE) та демонстрації розуміння того, як система може відмовити і як це відстежувати. Кандидат показав сильні логічні навички, але отримав пораду сповільнитися, приділити більше уваги деталізації складних частин та обов'язково включати обговорення trade-offs, що є ключем до отримання "pass" з високою впевненістю.