Systémový dizajn v Nutshell

Začnime. Tento článok som mal v hlave 2 roky a nikdy som ho nepísal, obávajúc sa, že by nebol dokonalý. Technologická krajina sa neustále mení a vyvíja a nástroje, ktoré dnes používate, môžu byť zastarané o 5 rokov neskôr. To je dôvod, prečo tu píšem základné koncepty systémového dizajnu. Môžeme ho vždy vylepšiť na základe našej infraštruktúry a požiadaviek. Ak narazím na iný rámec, napíšem ho ako pokračovanie tejto korešpondencie. Systémový dizajn je nevyhnutnou súčasťou vývoja softvéru. Musíte mať 30 000 stôp pohľadu pred vykopaním do špecifikácií. Programovacie jazyky pre všeobecné účely môžu byť použité všade, ale musíte najprv vedieť, kde ho použiť a ako ho použiť. Nasledujúce sú dôležité kroky, ktoré som narazil počas môjho výskumu (niekoľko tém nebude podrobne vysvetlené, pretože si zaslúžia svoj vlastný článok): UX Design & Komponenty Keďže s najväčšou pravdepodobnosťou nebudete vyvíjať CLI, je dôležité mať dobrý UX-UI. Musíte poznať dôležité komponenty a potom sa na nich zlepšiť, keď budete pokračovať. Stačia len dôležité. Napríklad: Klon Twitteru bude mať komponentu, kde sú napísané tweety. Bude mať používateľské profily, nasledovníkov, nastavenia súkromia atď. Klon spoločnosti Uber bude mať integráciu máp. Chatové messengery ako WhatsApp budú mať osobné správy a skupinové správy, možnosti postúpenia a zdieľania atď. Všetky aplikácie sociálnych médií padnú pod jeden dáždnik, všetky video streamingové platformy / OTT v inom a všetky filmové rezervácie / rezervácie aplikácií padnú pod iný. ╔═════════════════════════════════════╗ ║ TWITTER CLONE UI COMPONENTS ║ ╠═════════════════════════════════════╣ │ APPLICATION UI │ ├─────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ │ │ │ Profile │ │ Tweet │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Settings │ │ Messages │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────┘ Triedy / Podtriedy Ak premýšľate o objektovo orientovanom dizajne, je to jednoduchšie, ak uvediete všetky rôzne triedy, ktoré môžu byť potrebné vo vašom dizajne systému. To vám pomôže vyčistiť všetky objekty a potom môžete pokračovať v definovaní metód týkajúcich sa týchto tried. Napríklad klon Twitteru bude mať triedu "User Profiles" s atribútmi ako "Name", "Location" atď. ╔═════════════════════════════════════╗ ║ OBJECT-ORIENTED CLASS DESIGN ║ ╚═════════════════════════════════════╝ ┌─────────────────┐ │ User │ ├─────────────────┤ │ - name │ │ - location │ │ - email │ ├─────────────────┤ │ + post() │ │ + follow() │ └────────┬────────┘ │ ┌────────┴────────┐ │ │ ┌───▼────┐ ┌─────▼───┐ │Premium │ │ Basic │ │ User │ │ User │ └────────┘ └─────────┘ Dizajnové vzory Po vytvorení návrhu triedy môžete potom vybrať primeraný vzor návrhu, ktorý bude vyhovovať vašim potrebám. Napríklad, ak má vaša aplikácia informačný kanál, môžete zvážiť vzor návrhu Publisher-Subscriber. ╔═════════════════════════════════════╗ ║ PUBLISHER-SUBSCRIBER PATTERN ║ ╚═════════════════════════════════════╝ ┌──────────────┐ │ Publisher │ │ (News Feed) │ └──────┬───────┘ │ │ publish() │ ┌───▼────────────────┐ │ Message Broker │ └───┬────────────────┘ │ │ notify() │ ┌───┴───┬───────┬────────┐ │ │ │ │ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐ ┌───▼─┐ │Sub1 │ │Sub2 │ │Sub3 │ │Sub4 │ └─────┘ └─────┘ └─────┘ └─────┘ CDN / Serverless / API / Vyrovnávacia pamäť 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 │ └─────────────┘ Možná konzistentnosť vs. transakčná konzistentnosť 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] Akcia udalosti Správa udalostí je nevyhnutná, ak máte rôzne komponenty, ktoré sa snažia navzájom hovoriť.Od začatia žiadosti po splnenie odpovede musíte jasne poznať trasy, ktoré budú mať dátové balíky. ╔═════════════════════════════════════╗ ║ EVENT HANDLING FLOW ║ ╚═════════════════════════════════════╝ ┌──────────┐ Event ┌──────────┐ │Component │─────────────►│ Event │ │ A │ Fired │ Queue │ └──────────┘ └─────┬────┘ │ ┌─────▼─────┐ │ Handler │ └─────┬─────┘ │ ┌───────────┼───────────┐ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │Comp B │ │Comp C │ │Comp D │ └───────┘ └───────┘ └───────┘ SQL / NoSQL / Polyglot pretrvávanie V distribuovaných systémoch SQL počas sieťových oddielov zvyčajne uprednostňujete konzistenciu pred dostupnosťou. NoSQL databázy môžu byť použité na ukladanie polostrukturovaných údajov, kľúčových hodnôt párov, obrázkov a videí. Grafické databázy a databázy vyhľadávačov tiež patria pod databázy NoSQL. V distribuovaných NoSQL systémoch zvyčajne uprednostňujete dostupnosť a toleranciu oddielov, pričom akceptujete prípadnú konzistenciu. Podľa teórie CAP, v distribuovanom systéme, ktorý zažíva sieťové oddiely, musíte si vybrať medzi konzistenciou a dostupnosťou. Ak potrebujete kombináciu databáz SQL a NoSQL, nazývame to polyglotová vytrvalosť. ╔═════════════════════════════════════╗ ║ SQL/NoSQL/POLYGLOT PERSISTENCE ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Application Layer │ └──────────────┬──────────────────────┘ │ ┌───────┴────────┐ │ │ ┌──────▼──────┐ ┌─────▼────────────┐ │ SQL │ │ NoSQL │ │ Database │ │ Database │ ├─────────────┤ ├──────────────────┤ │ - ACID │ │ - Key-Value │ │ - Structured│ │ - Document │ │ - CA (CP) │ │ - Graph │ │ │ │ - AP │ └─────────────┘ └──────────────────┘ └────────┬────────┘ │ POLYGLOT PERSISTENCE Client-Side vs. Server-Side ukladanie dát Niekedy aplikácia používa úložisko mobilného zariadenia, na ktorom je nainštalovaná. Napríklad správy WhatsApp sú uložené v lokálnom úložisku smartfónu s voliteľným cloudovým zálohovaním. Niekedy sú všetky dáta uložené na serveroch. Napríklad všetky správy v službe Facebook Messenger sú uložené na serveroch Facebooku. Pred začatím vývojového cyklu musíte jasne definovať, ktoré komponenty by využívali zdroje servera a ktoré by využívali lokálne zdroje zariadenia. ╔═══════════════════════════════════════════════════╗ ║ 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 │ └──────────────┘ └──────────────┘ Optimalizované dátové štruktúry Každý riadok kódu, ktorý napíšete, zdaní server. Čím viac daní, tým viac budete musieť zaplatiť za jeho údržbu.To je dôvod, prečo je dobrou praxou písať optimalizovaný softvérový kód a používať dátové štruktúry, ktoré majú nižšiu časovú a priestorovú zložitosť. ╔═════════════════════════════════════╗ ║ 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 │ └─────────────────────────────┘ Nastavenie súkromia Používatelia vašej aplikácie musia mať možnosti na ochranu seba na internete. Musíte mať dobré možnosti ochrany osobných údajov. Napríklad v aplikácii WhatsApp môžete skryť svoju profilovú fotografiu, prečítať príjmy a naposledy vidieť. Môžete dokonca zablokovať niekoho, koho si myslíte, že je spam. +-----------------------------------------+ | PRIVACY SETTINGS | +-----------------------------------------+ +-----------------------------------------+ | User Privacy Panel | +-----------------------------------------+ | [ ] Show Profile Photo | | [X] Hide Last Seen | | [X] Hide Read Receipts | | [ ] Show Online Status | | [X] Block User | | | | [Save Settings] | +-----------------------------------------+ dodržiavanie Vaša aplikácia musí byť v súlade s požadovanými predpismi. Napríklad: 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 │ └───────────┘ └───────────┘ Bezpečnostné aspekty Zatiaľ čo bezpečnosť je veľmi široká téma, vo vašej počiatočnej analýze musíte zvážiť ochranu pred spamom a DDoS. Musíte mať správnu štruktúru IAM a silné politiky hesla. ╔═════════════════════════════════════╗ ║ 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 │ └───────────────────────────────────┘ Služby dostupné v oblasti nasadenia Ako naznačuje názov, všetky služby, ktoré uvažujete, musia byť k dispozícii v geografickom regióne, v ktorom máte v úmysle spustiť aplikáciu. Napríklad, ak plánujete spustiť aplikáciu v Číne, nemali by ste v návrhu aplikácie zvážiť rozhranie Facebook API, pretože by to nefungovalo. +---------------------------------------+ | GEOGRAPHICAL SERVICE AVAILABILITY | +---------------------------------------+ GLOBAL SERVICE MAP +--------------+ +--------------+ | USA | | China | +--------------+ +--------------+ | [+] Facebook | | [-] Facebook | | [+] Google | | [-] Google | | [+] AWS | | [+] Alibaba | | [+] WhatsApp | | [+] WeChat | +--------------+ +--------------+ Check Service Availability Before Launch! Analýza nákladov Pri zvažovaní možností sa pokúste vybrať rámce s otvoreným zdrojovým kódom s dobrou podporou komunity vývojárov. ╔═════════════════════════════════════╗ ║ 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 / Cloud / Hybridný Rozhodnite sa, či sa vaše dáta budú nachádzať on-prem, úplne v cloude, alebo čiastočne v cloude a čiastočne v cloude (hybrid). ╔═════════════════════════════════════╗ ║ DEPLOYMENT OPTIONS ║ ╚═════════════════════════════════════╝ ┌──────────────────────────────────────┐ │ Deployment Options │ └───────────┬──────────────────────────┘ │ ┌───────┼───────┐ │ │ │ ┌───▼───┐ ┌─▼────┐ ┌▼──────┐ │On-Prem│ │Cloud │ │Hybrid │ ├───────┤ ├──────┤ ├───────┤ │Local │ │ AWS │ │On-Prem│ │Servers│ │Azure │ │ + │ │ Data │ │ GCP │ │ Cloud │ │Center │ │ │ │ Mix │ └───────┘ └──────┘ └───────┘ │ ┌───▼────┐ │ VPC │ └────────┘ Horizontálne škálovanie / Vertikálne škálovanie a vyvažovanie zaťaženia Pri horizontálnom škálovaní umiestnite repliky aktuálneho servera DB/aplikácie a použite vyvažovač zaťaženia na vyváženie prevádzky medzi týmito inštanciami. Vo vertikálnom škálovaní zlepšujete systémovú konfiguráciu inštancie. Existuje určitý limit na to, čo môžete zlepšiť. Existujú aj iné úvahy - napríklad ak zväčšíte výpočet, musíte zodpovedajúcim spôsobom zvýšiť pamäť RAM. Múdrou stávkou by bolo mať spravodlivú kombináciu horizontálneho a vertikálneho škálovania. Vyrovnávače zaťaženia sa používajú na vyváženie prevádzky medzi rôznymi inštanciami. Vyrovnávače zaťaženia pomáhajú znižovať časy zastavenia systému. +-------------------------------------------------------------+ | 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 Získanie zákazníka a zachovanie zákazníka Integrujte analytiku, ako je analýza funnel a A / B testovanie, aby ste zlepšili svoju zákaznícku základňu. ╔═════════════════════════════════════╗ ║ CUSTOMER ACQUISITION & RETENTION ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Analytics Funnel │ ├─────────────────────────────────────┤ │ │ │ 1000 Users ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 500 Signups ▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 200 Active ▓▓▓▓ │ │ │ │ │ 100 Paid ▓▓ │ │ │ ├─────────────────────────────────────┤ │ A/B Testing │ │ ┌─────────┐ ┌─────────┐ │ │ │Version A│ │Version B│ │ │ │ 50% │ │ 50% │ │ │ └────┬────┘ └─────┬───┘ │ │ └──────┬────────┘ │ │ Compare │ └─────────────────────────────────────┘ Zhrnutie : ================================ 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 ================================ Tento rámec vám tiež pomôže objasniť otázky o návrhu systémov na úvodnej úrovni v ľubovoľnom najvyššom MNC. Keď som začal písať tento článok, mal som oveľa viac v mysli. musel som vystrihnúť obsah, pretože mnohé z tu uvedených konceptov môžu byť vysvetlené v samostatných článkoch. Ďakujem za čítanie, zostaňte v pohode. Ak máte akékoľvek otázky, prosím, neváhajte mi poslať e-mail. Môžete ma tiež kontaktovať cez Linkedin. Môžete ma tiež sledovať na X e-mailom e-mailom Linkedin → Linkedin → X X