Системный дизайн в Nutshell

Давайте начнем.Я имел эту статью в голове в течение 2 лет и никогда не писал ее, опасаясь, что это не будет идеальным. Технологический ландшафт постоянно меняется и развивается, а инструменты, которые вы используете сегодня, могут быть устаревшими 5 лет спустя. Системный дизайн является неотъемлемой частью разработки программного обеспечения. Вы должны иметь вид на 30 000 футов, прежде чем вы копаете в спецификации. Общие языки программирования могут быть использованы везде, но вы должны сначала знать, где использовать его и как его использовать. Ниже приведены важные шаги, с которыми я столкнулся во время моих исследований (некоторые темы не будут подробно объяснены, поскольку они заслуживают собственной статьи): UX дизайн и компоненты Поскольку вы, скорее всего, не будете разрабатывать CLI, наличие хорошего UX-UI важно. Вы должны знать важные компоненты и затем улучшить их по мере продвижения вперед. Достаточно только важных. Клон Twitter будет иметь компонент, в котором составляются твиты.У него будут пользовательские профили, последователи, настройки конфиденциальности и т.д. Клоны Uber будут интегрированы в карты. Чат-посланники, такие как WhatsApp, будут иметь сообщения от человека к человеку и групповые сообщения, возможности пересылки и обмена и т.д. Все приложения социальных сетей попадут под один зонт, все платформы потокового видео / OTT в другой, а все приложения для бронирования / бронирования фильмов попадут под другой. ╔═════════════════════════════════════╗ ║ TWITTER CLONE UI COMPONENTS ║ ╠═════════════════════════════════════╣ │ APPLICATION UI │ ├─────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ │ │ │ Profile │ │ Tweet │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Settings │ │ Messages │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────┘ Класс / Подкласс Если вы думаете об объектно-ориентированном дизайне, это проще, если вы перечислите все различные классы, которые могут потребоваться в вашем дизайне системы. Это помогает вычеркнуть все объекты, а затем вы можете приступить к определению методов, относящихся к этим классам. ╔═════════════════════════════════════╗ ║ OBJECT-ORIENTED CLASS DESIGN ║ ╚═════════════════════════════════════╝ ┌─────────────────┐ │ User │ ├─────────────────┤ │ - name │ │ - location │ │ - email │ ├─────────────────┤ │ + post() │ │ + follow() │ └────────┬────────┘ │ ┌────────┴────────┐ │ │ ┌───▼────┐ ┌─────▼───┐ │Premium │ │ Basic │ │ User │ │ User │ └────────┘ └─────────┘ Дизайн Patterns После того, как у вас есть дизайн класса, вы можете выбрать адекватный шаблон дизайна, который отвечает вашим потребностям. Например, если в вашем приложении есть новостной канал, вы можете рассмотреть шаблон дизайна 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 / Полиглотная стойкость В распределенных системах 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 Он-Прем / Облако / Гибрид Решите, будут ли ваши данные находиться на месте, полностью в облаке, или частично в облаке и частично на месте (гибрид). ╔═════════════════════════════════════╗ ║ 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 Электронная Электронная Linkedin Linkedin X X