Дизайн системи в нутриці

Давайте почнемо. Я мав цю статтю в голові протягом 2 років і ніколи не писав її, побоюючись, що вона не буде досконалою. Технологічний ландшафт постійно змінюється і розвивається, а інструменти, які ви використовуєте сьогодні, можуть бути застарілими через 5 років. Ось чому я пишу основні концепції системного дизайну тут. Ми завжди можемо відрегулювати його на основі нашої інфраструктури та вимог. Системний дизайн є невід'ємною частиною розробки програмного забезпечення. Ви повинні мати 30 000 футів погляду, перш ніж копати в специфіки. мови програмування загального призначення можуть бути використані скрізь, але ви повинні спочатку знати, де використовувати його і як використовувати його. Нижче наведено важливі кроки, з якими я зіткнувся під час своїх досліджень (деякі теми не будуть детально пояснені, оскільки вони заслуговують на власну статтю): UX Design & Компоненти Оскільки ви, швидше за все, не будете розробляти CLI, мати хороший UX-UI важливо. Ви повинні знати важливі компоненти, а потім вдосконалювати їх, як ви йдете далі. Клон Twitter буде мати компонент, де твіти розробляються.У нього будуть профілі користувачів, послідовники, налаштування конфіденційності і т.д. Клони Uber отримають інтеграцію карт. Чат-повідомники, такі як WhatsApp, матимуть особисті повідомлення та групові повідомлення, можливості пересилання та обміну і т.д. Всі програми соціальних мереж потраплять під один парасольку, всі платформи потокового відео / OTT в іншій, і всі програми бронювання / бронювання фільмів потраплять під інший. ╔═════════════════════════════════════╗ ║ TWITTER CLONE UI COMPONENTS ║ ╠═════════════════════════════════════╣ │ APPLICATION UI │ ├─────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ │ │ │ Profile │ │ Tweet │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Settings │ │ Messages │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────┘ Класи / Підкласи Якщо ви думаєте про об'єктно-орієнтований дизайн, це простіше, якщо ви перелічите всі різні класи, які вам можуть знадобитися у вашому проекті системи. Це допомагає виключити всі об'єкти, а потім ви можете приступити до визначення методів, що належать до цих класів. Наприклад, клон Twitter буде мати клас "Профілі користувача" з атрибутами, такими як "Назва", "Місцезнаходження" тощо. ╔═════════════════════════════════════╗ ║ OBJECT-ORIENTED CLASS DESIGN ║ ╚═════════════════════════════════════╝ ┌─────────────────┐ │ User │ ├─────────────────┤ │ - name │ │ - location │ │ - email │ ├─────────────────┤ │ + post() │ │ + follow() │ └────────┬────────┘ │ ┌────────┴────────┐ │ │ ┌───▼────┐ ┌─────▼───┐ │Premium │ │ Basic │ │ User │ │ User │ └────────┘ └─────────┘ Дизайн патентів Після того, як у вас є дизайн класу, ви можете вибрати адекватний шаблон дизайну, який відповідає вашим потребам. Наприклад, якщо у вашої програми є новинний потік, ви можете розглянути шаблон дизайну Publisher-Subscriber. ╔═════════════════════════════════════╗ ║ PUBLISHER-SUBSCRIBER PATTERN ║ ╚═════════════════════════════════════╝ ┌──────────────┐ │ Publisher │ │ (News Feed) │ └──────┬───────┘ │ │ publish() │ ┌───▼────────────────┐ │ Message Broker │ └───┬────────────────┘ │ │ notify() │ ┌───┴───┬───────┬────────┐ │ │ │ │ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐ ┌───▼─┐ │Sub1 │ │Sub2 │ │Sub3 │ │Sub4 │ └─────┘ └─────┘ └─────┘ └─────┘ CDN / Serverless / API / Кеш CDN is used to host static HTML content with lower latency. You can incorporate it in your infrastructure to reduce response time. You can reduce costs by using serverless architecture for simple grunt work, automation, or cron jobs. APIs help a lot in connecting disconnected systems and enabling segregation of concerns. Cache helps store temporary data, but the catch is that cache memory is the most expensive type of memory. So, you must have an optimized cache strategy. ╔═════════════════════════════════════╗ ║ CDN/SERVERLESS/API/CACHE STACK ║ ╚═════════════════════════════════════╝ ┌─────────┐ │ Client │ └────┬────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ CDN │◄───│ Static │ │ (Static) │ │ Content │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ Cache │◄───│ Hot │ │ │ │ Data │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ API │◄───│Serverless│ │ Gateway │ │Functions │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ │ Backend │ │ Server │ └─────────────┘ Можлива послідовність vs. транзакційна послідовність In eventual consistency, you can expect some delay in the transaction being considered "written." This is used in applications where a little delay may not affect the overall application. For example, a WhatsApp message may be delivered with a delay of 2-3 seconds, and that should not impact the overall user experience. You can use a NoSQL database to achieve this. In transactional consistency, you want the transaction to be committed instantly. For example, in a money transfer application, you want the money transferred immediately to reduce the risks of double spending. You can use a relational database to achieve this. ╔═════════════════════════════════════════════════════════════╗ ║ EVENTUAL vs TRANSACTIONAL CONSISTENCY ║ ╚═════════════════════════════════════════════════════════════╝ EVENTUAL CONSISTENCY TRANSACTIONAL CONSISTENCY ┌──────────────────┐ ┌──────────────────┐ │ Write Request │ │ Write Request │ └────────┬─────────┘ └────────┬─────────┘ │ │ ▼ ▼ ┌─────────┐ ┌─────────┐ │ NoSQL │ │ SQL │ │ DB │ │ DB │ └────┬────┘ └────┬────┘ │ │ ┌────▼────┐ ┌────▼────┐ │ Delay │ │Immediate│ │ 2-3 sec │ │ Commit │ └────┬────┘ └────┬────┘ │ │ ▼ ▼ [Eventually [Immediately Consistent] Consistent] Діяльність події Обробка подій є необхідною, коли у вас є різні компоненти, які намагаються спілкуватися один з одним.Від ініціації запиту до виконання відповіді, ви повинні чітко знати маршрути, які будуть виконуватися пакетами даних. ╔═════════════════════════════════════╗ ║ EVENT HANDLING FLOW ║ ╚═════════════════════════════════════╝ ┌──────────┐ Event ┌──────────┐ │Component │─────────────►│ Event │ │ A │ Fired │ Queue │ └──────────┘ └─────┬────┘ │ ┌─────▼─────┐ │ Handler │ └─────┬─────┘ │ ┌───────────┼───────────┐ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │Comp B │ │Comp C │ │Comp D │ └───────┘ └───────┘ └───────┘ SQL / NoSQL / Поліглот Persistence У розподілених системах SQL, під час мережевих розділів, ви зазвичай пріоритетуєте послідовність над доступністю. Бази даних NoSQL можуть використовуватися для зберігання напівструктурованих даних, пар ключових значень, зображень та відео. Бази даних Graph та бази даних пошукових систем також належать до баз даних NoSQL. У розподілених системах NoSQL ви зазвичай пріоритетуєте доступність та толерантність розділів, приймаючи можливу послідовність. Згідно з теоремою CAP, в розподіленій системі, що переживає мережеві розділи, ви повинні вибирати між послідовністю і доступністю. Якщо вам потрібна комбінація баз даних SQL і NoSQL, ми називаємо це поліглотною наполегливістю. ╔═════════════════════════════════════╗ ║ SQL/NoSQL/POLYGLOT PERSISTENCE ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Application Layer │ └──────────────┬──────────────────────┘ │ ┌───────┴────────┐ │ │ ┌──────▼──────┐ ┌─────▼────────────┐ │ SQL │ │ NoSQL │ │ Database │ │ Database │ ├─────────────┤ ├──────────────────┤ │ - ACID │ │ - Key-Value │ │ - Structured│ │ - Document │ │ - CA (CP) │ │ - Graph │ │ │ │ - AP │ └─────────────┘ └──────────────────┘ └────────┬────────┘ │ POLYGLOT PERSISTENCE Клієнт-сайт vs. сервер-сайт зберігання даних Іноді додаток використовує сховище мобільного пристрою, на якому він встановлений.Наприклад, повідомлення WhatsApp зберігаються в локальному сховищі вашого смартфона, з додатковим хмарним резервним кодом. Іноді всі дані зберігаються на серверах.Наприклад, всі повідомлення в Facebook Messenger зберігаються на серверах Facebook. Перед початком циклу розробки необхідно чітко визначити, які компоненти використовують ресурси сервера, а які використовують локальні ресурси пристрою. ╔═══════════════════════════════════════════════════╗ ║ CLIENT-SIDE vs SERVER-SIDE STORAGE ║ ╚═══════════════════════════════════════════════════╝ CLIENT-SIDE SERVER-SIDE ┌──────────────┐ ┌──────────────┐ │ Mobile │ │ Server │ │ Device │ │ Cluster │ ├──────────────┤ ├──────────────┤ │ ┌──────────┐ │ │ ┌──────────┐ │ │ │ WhatsApp │ │ │ │ Facebook │ │ │ │ Messages │ │ │ │Messenger │ │ │ │ (Local) │ │ │ │ Messages │ │ │ └──────────┘ │ │ └──────────┘ │ │ │ │ │ │ + Optional │ │ + Backup │ │ Cloud │ │ + Sync │ │ Backup │ │ + Access │ └──────────────┘ └──────────────┘ Оптимізовані структури даних Кожен ряд коду, який ви пишете, оподатковує сервер. Чим більше податку, тим більше вам доведеться платити, щоб підтримувати його. ╔═════════════════════════════════════╗ ║ OPTIMIZED DATA STRUCTURES ║ ╚═════════════════════════════════════╝ Data Structure Complexity O(1) ───────── Best (Hash Table) O(log n) ────── Good (Binary Tree) O(n) ───────── Acceptable (Array) O(n²) ───────── Poor (Nested Loops) O(2ⁿ) ───────── Worst (Exponential) ┌─────────────────────────────┐ │ Choose Lower Complexity │ │ = Less Server Tax │ │ = Lower Costs │ └─────────────────────────────┘ Налаштування конфіденційності Користувачі вашого додатка повинні мати варіанти, щоб захистити себе в інтернеті. Ви повинні мати хороші варіанти конфіденційності. Наприклад, в WhatsApp, ви можете приховати своє фото профілю, прочитати квитанції, і останнє побачення. Ви можете навіть заблокувати когось, кого ви вважаєте спамом. +-----------------------------------------+ | PRIVACY SETTINGS | +-----------------------------------------+ +-----------------------------------------+ | User Privacy Panel | +-----------------------------------------+ | [ ] Show Profile Photo | | [X] Hide Last Seen | | [X] Hide Read Receipts | | [ ] Show Online Status | | [X] Block User | | | | [Save Settings] | +-----------------------------------------+ Відповідність Ваша програма повинна відповідати необхідним нормам. Наприклад: If your application handles Protected Health Information (PHI) for covered entities, it should be HIPAA compliant. If your application is being launched in the EU, it should be GDPR compliant. ╔═════════════════════════════════════╗ ║ COMPLIANCE REQUIREMENTS ║ ╚═════════════════════════════════════╝ ┌──────────────────────────────────┐ │ Your Application │ └────────────┬─────────────────────┘ │ ┌──────┴──────┐ │ │ ┌─────▼─────┐ ┌────▼──────┐ │ HIPAA │ │ GDPR │ │Compliance │ │Compliance │ ├───────────┤ ├───────────┤ │ Medical │ │ EU │ │ PHI │ │ Privacy │ │ Protected │ │ Rules │ └───────────┘ └───────────┘ аспекти безпеки Хоча безпека є дуже широкою темою, у вашому початковому аналізі ви повинні розглянути захист від спаму та DDoS. Ви повинні мати належну структуру IAM та сильні політики паролів. ╔═════════════════════════════════════╗ ║ SECURITY LAYERS ║ ╚═════════════════════════════════════╝ ┌───────────────────────────────────┐ │ Security Layers │ ├───────────────────────────────────┤ │ Layer 5: 2FA Authentication │ ├───────────────────────────────────┤ │ Layer 4: IAM & Access Control │ ├───────────────────────────────────┤ │ Layer 3: DDoS Protection │ ├───────────────────────────────────┤ │ Layer 2: Spam Filtering │ ├───────────────────────────────────┤ │ Layer 1: Password Policy │ └───────────────────────────────────┘ Доступні послуги в області розгортання Як свідчить назва, всі послуги, які ви розглядаєте, повинні бути доступні в географічному регіоні, де ви маєте намір запустити додаток.Наприклад, якщо ви плануєте запустити додаток в Китаї, ви не повинні розглядати Facebook API у вашому дизайні додатків, оскільки це не спрацювало б. +---------------------------------------+ | GEOGRAPHICAL SERVICE AVAILABILITY | +---------------------------------------+ GLOBAL SERVICE MAP +--------------+ +--------------+ | USA | | China | +--------------+ +--------------+ | [+] Facebook | | [-] Facebook | | [+] Google | | [-] Google | | [+] AWS | | [+] Alibaba | | [+] WhatsApp | | [+] WeChat | +--------------+ +--------------+ Check Service Availability Before Launch! Аналіз витрат При розгляді варіантів спробуйте вибрати рамки з відкритим кодом з хорошою підтримкою спільноти розробників. ╔═════════════════════════════════════╗ ║ COST OPTIMIZATION ║ ╚═════════════════════════════════════╝ ┌────────────────────────────────────┐ │ Cost Optimization │ ├────────────────────────────────────┤ │ │ │ Open Source >>> Proprietary │ │ (Lower Cost) (Higher Cost) │ │ │ │ Serverless >>> Always-On │ │ (Pay per use) (Fixed Cost) │ │ │ │ Cache >>> DB Query │ │ (Expensive) (Cheaper) │ │ │ └────────────────────────────────────┘ Balance Cost vs Performance On-Prem / Хмарний / Гібридний Вирішіть, чи будуть ваші дані перебувати on-prem, повністю в хмарі, або частково в хмарі і частково в хмарі (гібрид). ╔═════════════════════════════════════╗ ║ DEPLOYMENT OPTIONS ║ ╚═════════════════════════════════════╝ ┌──────────────────────────────────────┐ │ Deployment Options │ └───────────┬──────────────────────────┘ │ ┌───────┼───────┐ │ │ │ ┌───▼───┐ ┌─▼────┐ ┌▼──────┐ │On-Prem│ │Cloud │ │Hybrid │ ├───────┤ ├──────┤ ├───────┤ │Local │ │ AWS │ │On-Prem│ │Servers│ │Azure │ │ + │ │ Data │ │ GCP │ │ Cloud │ │Center │ │ │ │ Mix │ └───────┘ └──────┘ └───────┘ │ ┌───▼────┐ │ VPC │ └────────┘ Горизонтальне масштабування / Вертикальне масштабування та балансирування навантаження У горизонтальному масштабуванні ви розміщуєте репліки поточного DB-сервера / сервера додатків і використовуєте балансор навантаження для балансування трафіку між цими інстанціями. У вертикальному масштабуванні ви покращуєте системну конфігурацію інстанції. Є деякі межі того, що ви можете поліпшити. Є й інші міркування - наприклад, якщо ви збільшите обчислення, ви повинні збільшити оперативну пам'ять відповідно. Розумною ставкою було б мати справедливу суміш горизонтального і вертикального масштабування. Балансири навантаження використовуються для балансування трафіку між різними інстанціями. Балансири навантаження допомагають скоротити час зупинки системи. +-------------------------------------------------------------+ | HORIZONTAL & VERTICAL SCALING WITH LOAD BALANCERS | +-------------------------------------------------------------+ HORIZONTAL SCALING VERTICAL SCALING +---------------+ +---------------+ | Load Balancer | | Upgrade | +-------+-------+ | CPU + RAM | | +-------+-------+ | | +-------------+-------------+ | | | | | v v v (and v) v +---+ +---+ +---+ +---------------+ |DB1| |DB2| |DB3|... | Powerful | +---+ +---+ +---+ | Server | +---------------+ Add more servers Improve single server Придбання та утримання клієнтів Включіть аналітики, такі як аналітика фуннелів та тестування A / B, щоб поліпшити вашу клієнтську базу. ╔═════════════════════════════════════╗ ║ CUSTOMER ACQUISITION & RETENTION ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Analytics Funnel │ ├─────────────────────────────────────┤ │ │ │ 1000 Users ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 500 Signups ▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 200 Active ▓▓▓▓ │ │ │ │ │ 100 Paid ▓▓ │ │ │ ├─────────────────────────────────────┤ │ A/B Testing │ │ ┌─────────┐ ┌─────────┐ │ │ │Version A│ │Version B│ │ │ │ 50% │ │ 50% │ │ │ └────┬────┘ └─────┬───┘ │ │ └──────┬────────┘ │ │ Compare │ └─────────────────────────────────────┘ Резюме : ================================ SYSTEM DESIGN IN A NUTSHELL 17 Core Concepts ================================ START HERE | ↓ 1. UX DESIGN & COMPONENTS → Design UI elements → Profile, messages, feeds | ↓ 2. CLASSES & SUBCLASSES → Define objects → User profiles with attributes | ↓ 3. DESIGN PATTERNS → Publisher-Subscriber → For news feeds | ↓ 4. INFRASTRUCTURE STACK → CDN for static content → Serverless functions → API Gateway → Cache strategy | ↓ 5. CONSISTENCY MODELS → Eventual (NoSQL) → Transactional (SQL) | ↓ 6. EVENT HANDLING → Request to response → Data packet routes | ↓ 7. DATABASE STRATEGY → SQL: Structured data → NoSQL: Key-value, docs → CAP Theorem considerations → Polyglot Persistence | ↓ 8. DATA STORAGE → Client-side (local) → Server-side (cloud) → Hybrid approach | ↓ 9. OPTIMIZED DATA STRUCTURES → Lower time complexity → Lower space complexity → Reduce server tax | ↓ 10. PRIVACY SETTINGS → Hide profile info → Block users → Read receipts control | ↓ 11. COMPLIANCE → HIPAA for medical PHI → GDPR for EU users | ↓ 12. SECURITY LAYERS → DDoS protection → IAM structure → 2FA authentication → Password policies → Spam filtering | ↓ 13. GEOGRAPHICAL SERVICES → Check availability → Regional restrictions → Example: Facebook in China | ↓ 14. COST OPTIMIZATION → Open source frameworks → Serverless options → Balance cost vs performance | ↓ 15. DEPLOYMENT OPTIONS → On-Premises → Cloud (AWS/Azure/GCP) → Hybrid approach → VPC considerations | ↓ 16. SCALING STRATEGIES → Horizontal: Add replicas → Vertical: Upgrade config → Load balancers → Mix both approaches | ↓ 17. CUSTOMER ANALYTICS → Funnel analytics → A/B testing → Acquisition & retention ================================ KEY TAKEAWAYS ================================ ★ 30,000 ft view first ★ Design before coding ★ Consider all 17 aspects ★ Balance trade-offs ★ Optimize for scale ★ Security & compliance ★ Cost-effective choices ================================ Ця рамка також допоможе вам зрозуміти питання інтерв'ю системного дизайну на початковому рівні в будь-якому верхньому МНК. Коли я почав писати цю статтю, у мене було набагато більше в думці. Дякую за читання, будьте в курсі. Якщо у вас є будь-які питання, будь ласка, не забудьте надіслати мені електронну пошту. Ви також можете зв'язатися зі мною через Linkedin. Ви також можете слідувати за мною на X Електронна Електронна Лінкейн Лінкейн X X