Vocabulary for System Design Interviews
Необхідний англійський словник для інтерв’ ю з проектуванням систем — масштабованість, надійність, бази даних і розподілені системи з поясненнями та прикладами.
Інтерв’ю з системним проектуванням тестують вашу здатність думати про масштабну архітектуру програмного забезпечення — і пояснити ваше мислення чітко англійською мовою. Знання правильного словника не є обов’ язковим: співбесідник слухає конкретні терміни, які сигналізують, що ви розумієте компроміси, які в цьому беруть участь.
Цей підручник містить необхідний вам словниковий запас, розділений за темами.
Словник лексикографії
Ці терміни з’ являються майже у кожній дискусії щодо проектування системи:
| Term | Definition | Example sentence |
|---|---|---|
| horizontal scaling | Adding more machines to handle load | ”We can scale horizontally by adding more API server instances behind the load balancer.” |
| vertical scaling | Upgrading the capacity of a single machine | ”Vertical scaling is simpler but has a hard ceiling — you can only add so much CPU and RAM to one machine.” |
| load balancer | Distributes incoming traffic across servers | ”The load balancer uses round-robin to distribute requests across our three application servers.” |
| stateless | Server does not store client session data between requests | ”Making the API stateless allows us to scale horizontally without sticky sessions.” |
| auto-scaling | Automatically adding/removing instances based on demand | ”We use auto-scaling to handle traffic spikes during peak hours without over-provisioning.” |
| sharding | Splitting a database across multiple machines | ”We shard by user ID — each shard holds accounts for a specific range.” |
| partitioning | Dividing data logically (often used interchangeably with sharding) | “Horizontal partitioning splits rows; vertical partitioning splits columns.” |
Надійність і доступність словарю
- “Ми націлюємося на 99,9% доступності - це дозволяє нам приблизно 8,7 годин простою на рік.” *
| Term | Definition |
|---|---|
| SLA (Service Level Agreement) | A contract defining the expected availability or performance |
| SLO (Service Level Objective) | An internal target, e.g., 99.9% uptime |
| SLI (Service Level Indicator) | A metric measuring actual performance |
| failover | Automatically switching to a backup system when the primary fails |
| replication | Copying data to multiple locations for redundancy |
| single point of failure | A component whose failure would bring down the entire system |
| redundancy | Having backup components to avoid single points of failure |
| graceful degradation | The system continues partially functioning under failure |
| circuit breaker | Stops retrying a failing service to prevent cascade failures |
В контексте:
- “Головним ризиком у цій конструкції є те, що база даних є єдиною точкою відмови. Я б додав репліку для читання і автоматичне відключення для вирішення цього питання.”*
База даних словників
“Для цього випадку використання, я б схилявся до реляційної бази даних — у нас є добре визначені схеми і потрібні ACID гарантії.”
| Term | Definition |
|---|---|
| ACID | Atomicity, Consistency, Isolation, Durability — guarantees for relational databases |
| BASE | Basically Available, Soft state, Eventually consistent — common in NoSQL |
| eventual consistency | Data will become consistent across nodes, but not immediately |
| strong consistency | All reads return the most recent write |
| CAP theorem | A distributed system can guarantee only two of: Consistency, Availability, Partition tolerance |
| read replica | A copy of the database used only for read queries |
| write-through cache | Data is written to cache and database simultaneously |
| write-back cache | Data is written to cache first, then asynchronously to the database |
| N+1 problem | Performance issue where one query generates N additional queries |
Кэшування словника
- “Ми можемо встановити кеш перед базою даних, щоб зменшити затримку читання. Я б використав політику виключення LRU, враховуючи, що шаблони доступу не є однорідними. “*
| Term | Definition |
|---|---|
| cache hit | Requested data found in cache |
| cache miss | Requested data not in cache — must fetch from source |
| cache eviction | Removing data from cache to make room for new entries |
| LRU (Least Recently Used) | Evicts data not accessed recently |
| TTL (Time To Live) | How long data stays in cache before expiring |
| cache invalidation | Removing or updating stale data from cache |
| CDN (Content Delivery Network) | Distributed servers that cache static assets near users |
Словник і словник-довідник
- “Щоб від’ єднати службу сповіщень від служби замовлень, я б запропонував чергу повідомлень. Служба замовлення публікує подію; служба сповіщення споживає її асинхронно.”*
| Term | Definition |
|---|---|
| message queue | A buffer that holds messages between producer and consumer |
| producer / consumer | Services that send / receive messages |
| pub/sub (publish/subscribe) | Pattern where publishers broadcast events to multiple subscribers |
| dead letter queue | Holds messages that could not be processed successfully |
| idempotency | Processing the same message multiple times produces the same result |
| at-least-once delivery | Message will be delivered, but may arrive more than once |
| exactly-once delivery | Each message is delivered and processed exactly one time |
Корисні фрази для обговорення проектування системи
- “Дозвольте мені почати з архітектури високого рівня, а потім просунутися до компонентів.” *
- “Вузьким місцем у цьому проекті є база даних. Ось як я б це вирішив».*
“Компроміс тут - це послідовність проти доступності - залежно від вимог, я б вибрав по-іншому.”
“Зважаючи на масштабні вимоги — 10 мільйонів щоденних активних користувачів — горизонтальне масштабування не підлягає обговоренню.”
“Я роблю тут спрощене припущення: що читає значно переважає число пише. Чи це відповідає вимогам?»
Завдяки цьому словниковому запасу ви зможете плавно переходити від одного технічного поняття до іншого і вільно обговорювати компроміси — саме це і дає вам можливість отримати нагороду під час інтерв’ ю з розробкою системи.
Національний гімн: вірші та поезія
Багато розробників, які вивчають професійну англійську, знаходять тонкі відмінності у фразуваннях неймовірно складними. Це не просто про те, щоб знати * що * сказати; це про передачу вашого значення точно і ефективно в командному середовищі. Здається невеликою зміна у формулюванні може кардинально змінити тон запитання, вплинути на отриману зворотню зв’ язок, або навіть вплинути на прийняття запропонованого рішення. Розгляньте різницю між заявою «Це потрібно виправити» проти «Я виявив потенційне в’язке місце продуктивності, яке потребує оптимізації». Останнє негайно обрамляє проблему як щось, що потрібно вирішувати проактивно і спільно.
Поширений сценарій під час перегляду коду. Отримавши відгук на кшталт “Це не читається”, можна відчувати себе відверто. Більш конструктивний підхід, використовуючи такі фрази, як « Чи можемо ми дослідити переробку цього розділу для поліпшення читабельності? Можливо, додавання деяких коментарів, що пояснюють логіку, допоможе», демонструє готовність обговорювати і вчитися, сприяючи позитивній взаємодії. Аналогічно, в обговореннях Slack щодо запитів на витягування, уникайте тупих заяв. Замість того, щоб сказати «Це неправильно», спробуйте «Я бачу проблему з [спеціальним аспектом]. Чи можемо ми обговорити, як найкраще вирішити це?» Сфокусування на що і як, а не на особистому судженні, значно зменшує оборону і заохочує продуктивне вирішення проблем. Пам’ятайте, чітке спілкування не тільки про технічну точність; це про будівництво довіри і взаєморозуміння в межах вашої команди. Формування запитів як «Давайте розслідуємо…» або «Я б хотів запропонувати…» показує смирення і бажання спільного розуміння.
Іншим частим викликом є опис * чому * за рішеннями проектування. Просто сказати: «Я використовував цю базу даних» недостатньо. Поясніть причину: « Ми обрали PostgreSQL через його надійні можливості керування транзакціями, які є критичним фактором для забезпечення послідовності даних у нашій системі обробки замовлень великого обсягу ». Використання таких фраз, як « щоб забезпечити масштабованість », « щоб зменшити затримку » або « щоб дотримуватися найкращих практик » додає контексту і демонструє глибше розуміння вимог системи. Це також надає змогу рецензентам і зацікавленим особам зрозуміти * чому * ви зробили певний вибір, що може бути безцінним під час обговорення про компроміси.
І, нарешті, не бійтеся визнавати невизначеність. Фрази на кшталт «Я все ще досліджую варіанти для…» або «Давайте зробимо прототип, щоб оцінити його можливості» є цілком прийнятними — демонструючи, що ви відкриті для ітерації і адаптації вашого підходу на основі нової інформації.
# Example: Using `docker compose` to start a simple web application
docker compose up -d --buildЦя команда демонструє використання docker compose, інструменту для визначення і запуску багатоконтейнерних програм Docker. Прапорець -d запускає контейнери в відокремленому режимі (у фоні), а --build забезпечує, що всі необхідні зображення будуть створені перед запуском програми. Це поширена фраза, що використовується для опису розгортання і управління складними системами, і розуміння її компонентів має вирішальне значення при обговоренні масштабованості і операційних питань під час інтерв’ю з проектуванням системи.