System Design е интервюто, на което най-ясно личи колко сениър си. Защо? Защото повечето неща не можеш да ги заучиш - идват от менторство или години работа върху сериозни продукти. В това ръководство - mental loop стъпка по стъпка, кои са честите грешки, и как да оставиш силно впечатление дори с 2-3 години опит.
System Design ≠ кодинг
System Design тества способността ти да накараш цяла система да работи като едно цяло - компоненти в синхрон, поток на данните, обработка, изпращане. Това е място, където трябва да покажеш мислене за продукта, не за един клас или функция.
Clarify the problem (тук убиваш или печелиш интервюто)
Въпросите винаги са широки - "дизайнирай rate limiter", "дизайнирай chat app". Твоята работа е НЕ да започнеш да решаваш, а да стесниш скоупа. Това е грешка номер 1 - повечето кандидати веднага скачат на решение.
Не приемай нищо - scale, users, reads, latency, език, платформа. Винаги питай. Аналогия: в реална работа ако решиш грешния проблем перфектно, на клиента не му пука колко добре е направено. Може да си направил най-страхотната система - не я искат.
Чеклист да зададеш
Преди да започнеш да рисуваш
- •What is the MVP scope (понякога P0 в бизнес контекст)?
- •Кои са юзърите и какви са очакванията им?
- •Constraints: scale, traffic, consistency, бюджет?
- •Non-functional: uptime 99.99% или 99.999%?
- •Latency: 10ms, 100ms, или нямам ограничение?
Identify core use cases
Не nice-to-haves
- •Кое е абсолютно нужно за P0?
- •Аналогия с кола: гуми, фарове, двигател, гориво
- •Не правим багажник, климатроник, нав-система
- •Без тези функционалности продуктът не работи
Core requirements (functional + non-functional)
След clarify - какви точно са основните функционалности и какви non-functional изисквания. Тук правиш първоначалния списък от 5-7 точки. Не вкарвай всичко - само това, без което системата не съществува.
Максимум 3. Пример: банкова система → consistency на 100% е приоритет №1. Scalability, availability, latency идват после. Не казвай "трябва да е fast, scalable, available, consistent, durable" - звучи като junior. Сениърите избират.
High-level архитектура (4-5 компонента, макс 6)
High-level означава "отгоре-отгоре" - НЕ advanced/детайлно (честа терминологична грешка). Минимум компоненти: Client → API Gateway → Application Layer → DB / Cache / Workers. Без типове, форми, submission workflow в този момент - първо потвърди потока, после задълбочавай.
Златна среда: 4-5 компонента. В редки случаи 6. Над 7-8 загубваш и себе си, и интервюиращия. Държи се клар, дава ти място за дълбочина по-късно.
Deep dive с trade-offs (тук показваш сениърност)
Колкото по-сениър си, толкова повече от работата ти е да откриваш trade-offs - няма "вярно/грешно", има плюсове и минуси. Това е точно където разликата между мид и сениър се вижда.
Data stores - кога кое
- •User profiles → SQL или NoSQL според структурата
- •Search → Elasticsearch (full-text search)
- •Logs/metrics → time-series база (InfluxDB, Prometheus)
- •Real-time analytics → Kafka + processing
Аналогия за избор
- •Имаш набор инструменти: тесла, чук, отверка, лепило
- •За пирона - не лепило, а чук
- •За винта - не чук, а отверка
- •Знание на trade-offs = знание кой инструмент кога
За scaling - не просто "horizontal vs vertical". Покажи: database sharding, load balancing, CDN, partitioning, geographic replication. Конкретен пример: Meta има отделни сървъри за Eastern Europe, North/Central/West/South Europe. Банка по време на война - дейтата трябва да я има и другаде освен в зоната на конфликт.
Reliability + monitoring
Следвай къде интервюиращият те бута. Ако те бута към тема, която знаеш добре - задръж там 6-10 минути от 40-те. Не претупвай силните си страни. Мониторингът ти дава подсказки за останалата част на дизайна - какво monitor-ваш показва какво е критично.
Представи си реалния live use case. За банка: да изтегля парите си когато искам. Да не мога да платя 5 лв. два пъти ако имам само 5. Тези критични пътеки определят priorities-те ти в дизайна.
Mental loop за всяко System Design интервю
- 1Clarify - изясни проблема (НЕ започвай да решаваш)
- 2Estimate - юзъри, критични точки, P0/MVP
- 3High-level design - 4-5 компонента, общ flow
- 4Confirm - "Правилно ли разбирам, че така ще работи?" преди да продължиш
- 5Deeper choices с trade-offs - data models, бази, технологии
- 6Infra layer - caching, queues, load balancers
- 7Reliability + monitoring - какво следиш и защо
Чести диаграми, които да владееш
High-level system diagram
4-5 компонента максимум. Общ flow на данните. Лесна за четене - не претрупана.
Data flow diagram
Целият software engineering е data flow. Пример: 5 лв. влизат - къде отиват, как се записват, как се синкват? Ако платя едновременно 5 лв. на 2 места - как двете системи разбират че нямам пари?
Component diagram
Изолирай един компонент (напр. API Gateway при update). Отделна малка диаграма с до 6 компонента. По-добре от 25-30 стрелки на главната.
Database schema
Ако времето позволява. Не задължителна, но добавя дълбочина. Покажи foreign keys, индекси, partitioning.
Мисли в layers. Пример: user харчи 5 лв. с телефона → процесинг → storage → касова бележка → опит за второ плащане спрян от мониторинга → ако парите са загубени без user да ги е харчил, обажда се в банката за връщане. Това е сениърско мислене - не "имам endpoint, той прави нещо".
Тест за System Design ниво - 10 мин