Vocabulary

Single point of failure (SPOF) = part of a system that, if it fails, will stop the entire system from working.
Celebrity problem = Excessive access to a specific shard could cause server overload. Imagine data for Katy Perry, Justin Bieber, and Lady Gaga all end up on the same shard. For social applications, that shard will be overwhelmed with read operations. To solve this problem, we may need to allocate a shard for each celebrity. Each shard might even require further partition.
Clients: Multiple mobile devices and laptops denoting the clients.
CDN: The clients would get static data from the CDN.
Load balancer: The clients would talk to a load balancer for dynamic data.
Application servers: There would be many application servers behind the load balancer.
Database: The application servers would talk to one or more SQL/NoSQL servers with some replication/sharding/partitioning involved.
Microservices: The application servers would talk to other internal servers if the system has a microservices architecture. Example: Auth Service.
Queue: The application servers would add some events/messages to a queue with certain workers listening to the queue for events.
Cache: The application servers might fetch data from the cache before hitting the database.

Considerations

Part 1

Vertical scaling
Preprocessing and cron job
Backups=resilience=backup chef freelancer
Horizontal scaling=more chefs
Microservices=each chef is responsible for some sort of meal
Load balancing
Logging & monitoring
Decoupling (separation of concerns)
Extensibility

Part 2

For a Read-Heavy System - Consider using a Cache.
For a Write-Heavy System - Use Message Queues for async processing
For a Low Latency Requirement - Consider using a Cache and CDN.
Need 𝐀tomicity, 𝐂onsistency, 𝐈solation, 𝐃urability Compliant DB - Go for RDBMS/SQL Database.
Have unstructured data - Go for NoSQL Database.
Have Complex Data (Videos, Images, Files) - Go for Blob/Object storage.
Complex Pre-computation - Use Message Queue & Cache.
High-Volume Data Search - Consider search index, tries or search engine.
Scaling SQL Database - Implement Database Sharding.
High Availability, Performance, & Throughput - Use a Load Balancer.
Global Data Delivery - Consider using a CDN.
Graph Data (data with nodes, edges, and relationships) - Utilize Graph Database.
Scaling Various Components - Implement Horizontal Scaling.
High-Performing Database Queries - Use Database Indexes.
Bulk Job Processing - Consider Batch Processing & Message Queues.
Server Load Management & Preventing DOS Attacks- Use a Rate Limiter.
Microservices Architecture - Use an API Gateway.
For Single Point of Failure - Implement Redundancy.
For Fault-Tolerance and Durability - Implement Data Replication.
For User-to-User fast communication - Use Websockets.
Failure Detection in Distributed Systems - Implement a Heartbeat.
Data Integrity - Use Checksum Algorithm.
Efficient Server Scaling - Implement Consistent Hashing.
Decentralized Data Transfer - Consider Gossip Protocol.
Location-Based Functionality - Use Quadtree, Geohash, etc.
Avoid Specific Technology Names - Use generic terms.
High Availability and Consistency Trade-Off - Eventual Consistency.
For IP resolution & Domain Name Query - Mention DNS (Domain Name System).
Handling Large Data in Network Requests - Implement Pagination.
Cache Eviction Policy - Preferred is LRU (Least Recently Used) Cache.

My Framework

Frontend (functionality, components) — Web, Mobile (native, cross-platform, PWA=progressive web app)
Backend (micro-services, REST & GraphQL API, database (NoSQL, SQL, special types), message queue, polling & streaming, caching, rate limiting) — Redis, RabbitMQ, Celery, Kafka
Infrastructure (regions, users, latency, throughput, scalability, availability=fault tolerance=redundancy, LB, consistency, replication & sharding)

Performance (less latency, high throughput), scalability, availability, reliability=no error, consistency=same results. CAP.

Performance: The amount of work that the system does. Increasing performance means that the system should be able to do more amount of work.
Scalability: A service is said to be scalable if when we increase the resources in a system, it results in increased performance in a manner proportional to the resources added.
Availability: uptime, ability to respond to requests, be operational and accessible, measure of how often a system is available for use.
Resilience/reliability: ability to handle failures and continue to function. Refers to the ability of a system to perform its intended functions under specified conditions for a specified period of time. A reliable system is one that can be counted on to work consistently and dependably, without failing or producing errors. Reliability is the outcome and resilience is the way you achieve the outcome.
Consistency: ability to maintain the same level of performance or behavior over time, refers to the ability of a system or service to provide the same results every time it is used, under the same conditions. In other words, it is the measure of how predictable a system is.

CI/CD — Testing (functional and non-functional), K8s, Cloud (IaaC), feature flags, deployment strategies
Monitoring and logging — metrics, can be used to decide when to scale out and down the system. Manage risks.

Scaling. Тут важно понимать, что затык чаще всего возникает в реляционной БД, как можно этого избежать при помощи sharding или используя различные NoSQL, типа MongoDB.
На уровне сервисов можно поговорить про load balancing и некоторые его стратегии. Любая система должна загружать сервера более-менее равномерно.
Fail-safe (aka eliminate single point of failure, aka consistency). Любая нарисованная вами на доске архитектура для решения вопроса должна позволять любой своей части выйти из строя в любое время. Тут можно дополнительно рассказать про Netflix chaos monkey и как это круто =).
Replication. Любой stateful сервис, любая часть системы должна позволять перезагрузку и выход из строя в любой момент. Для этого нужно, чтобы данные были на это время были доступны где-то еще.
Master election. Если вы можете подробно рассказать про алгоритм выбора лидера при отказах и восстановлениях, например Raft или Paxos, то считайте, что прошли интервью.
Performance (обычно про caching и load balancing), рассказать несколько стратегий load balancing и про разные уровни кэша, рассказать про Memcached или Redis, и примеры их использования на практике, рассказать про географический load balancing, синхронизацию данных между несколькими датацентрами.
Очень важной частью распределенных систем является обмен сообщениями и logging, поэтому практическое знакомство с RabbitMQ, Amazon SQS/SNS, Kafka очень поможет.
Также помните про мониторинг системы. Какие данные вы хотите измерять, и какие критерии "здоровья" системы вы выберете?
Deployment. Контейнеры типа docker, управление ими при помощи mesos, проблемы deployment распределенных систем тоже могут пригодиться.

Systems Expert Vision (from course)

Important aspects to keep in mind while designing a scalable distributed system

How the data will be partitioned and replicated across servers. The first one is for scalability and performance, and the second is for availability and durability.

Foundational system design knowledge

Client/server model → Network protocols, how data is transferred between computers
Databases

Key characteristics of system

The things that trading off when selecting the solution: availability, latency, throughput, consistency, redundancy

Actual components of system — the thing

Load balancer, proxy, cache, rate limiting, leader election

Real products that actually you can use in system as component or to achieve some characteristics — tools that you can use to build up tools

Zookeeper, Kafka, Redis, Amazon S3