Я побував по обидва боки проєктування баз даних.
- На співбесідах усе виглядає акуратно і чисто.
- У реальному житті все здається хаотичним, непередбачуваним і сповненим сюрпризів.
Дозвольте мені пояснити обидва випадки, крок за кроком, щоб ви чітко побачили різницю.
Підхід на співбесіді: чітко та вражаюче
Під час співбесід часу обмаль, а очікування чіткі. Ви не створюєте повноцінну систему, а лише демонструєте свій спосіб мислення. Ось чому більшість співбесід мають такий вигляд:
Приклад: застосунок для доставки їжі (наприклад, Swiggy/Zomato)
- Таблиця Users з полями id, name, email.
- Таблиця Restaurants з полями id, name, location.
- Таблиця Orders з полями user_id, restaurant_id, total_amount, status.
- Таблиця Order_Items з полями order_id, item_name, price.
- Таблиця Payments з полями order_id, amount, method, status.
А потім додаєте останні штрихи:
- «Ми нормалізуємо ситуацію, щоб уникнути надлишковості».
- «Ми додамо індекси для user_id та restaurant_id».
- «Для масштабування ми будемо розподіляти дані за user_id і використовувати кешування».
Ось і все. Схема виглядає чіткою, логічною і її легко пояснити за 10 хвилин.
На співбесідах ніхто не запитує:
- «Що робити, якщо платежі тричі не пройдуть?»
- «Як ви обробляєте повернення коштів або промокоди?»
- «Що відбувається, коли накопичується мільярд рядків і потрібно додати новий стовпець?»
Тому що мета інтерв’юера не полягає в тому, щоб перевірити реалії продакшену.
Отже, співбесіди — це як створення проекту будинку. На папері все виглядає гарно.
Реальне життя: безлад і компроміси
Тепер поговоримо про реальні системи. У той момент, коли ви починаєте створювати щось на зразок застосунку для доставки їжі, все дуже швидко ускладнюється.
Та таблиця «Orders»? Вона розростається до багатьох:
- orders (основні деталі замовлення)
- order_items (оскільки одне замовлення може містити багато товарів)
- order_discounts (оскільки клієнти використовують купони)
- order_payments (оскільки замовлення іноді мають кілька платежів)
- order_payment_attempts (оскільки платежі не проходять і повторюються)
- order_refunds (оскільки бувають скасування)
- order_audit_logs (оскільки вам потрібна історія для підтримки та дотримання вимог)
Вже заплутано, правда? А це лише одна частина системи.
Проблеми з продуктивністю
На співбесіді ми все нормалізуємо. Але в реальних системах занадто багато JOIN вбивають продуктивність.
Наприклад: для отримання одного замовлення разом з його товарами, знижками та платежами потрібно 7+ JOIN. Це занадто повільно для користувачів, які чекають відповіді в застосунку.
Тож ми порушили «чисті» правила і денормалізували деякі дані в зручну для читання модель та зберегли її в кеші Redis.
Біль міграцій
В інтерв’ю ви кажете: «Ми додамо стовпець для delivery_instructions».
У реальному житті таблиця orders вже має 300 мільйонів рядків. Додавання стовпця може заблокувати таблицю на кілька годин.
Треба:
- Додати стовпець без зупинки системи
- Поступово заповнити його даними невеликими порціями.
- Перевірити можливість відкату змін у тестовому середовищі.
- Контролюйте затримку реплікації.
На безпечне впровадження цієї «простої колонки» пішло два тижні.
Бізнес-правила переписують схеми
Спочатку в таблиці замовлень була лише одна колонка payment_status.
Але фінансовий відділ сказав: «Нам потрібні часткові платежі, кілька спроб і розрахунки з банками».
Це означало створення нових таблиць: order_payments, order_payment_attempts, settlement_records.
Те, що на початку було чітким дизайном, постійно змінювалося разом з розвитком бізнес-правил.
Відповідність вимогам та аудити
Ніхто на співбесідах не запитує: «Як ви будете відстежувати кожну зміну даних для регуляторних аудитів?».
Але у фінтеху чи банківській справі це обов’язково.
Ми мали створити audit_trails, що зберігають:
- що змінилося
- старе значення
- нове значення
- хто змінив це
- коли це змінилося
Без цього ми б не пройшли перевірку на відповідність вимогам.
Індекси не завжди корисні
Під час співбесід ви з гордістю заявляєте:
«Ми додамо індекс до email для швидшого пошуку».
У реальних системах індекси прискорюють читання, але уповільнюють запис. У якийсь момент у нас було так багато індексів, що вставка даних уповільнилася на 40%. Нам довелося обережно видалити та переробити індекси.
Реальна різниця: співбесіда та реальне життя
Якщо зіставити обидва досвіди, контраст виявляється величезним.
- На співбесіді сутностей небагато. У реальному житті їх кількість стрімко зростає.
- На співбесіді нормалізація — золоте правило. У реальному житті денормалізація рятує продуктивність.
- На співбесіді масштабування — це лише модне слово. У реальному житті масштабування означає партиціювання даних, контроль за кешем та планування міграцій.
- На співбесіді міграції згадуються в одному реченні. У реальному житті міграції можуть тривати тижнями й ламати продакшен, якщо їх не виконувати обережно.
- На співбесіді ніколи не обговорюється питання дотримання вимог.
Уроки, які я засвоїв
- Ідеальної схеми не існує. Все, що ви розробляєте сьогодні, завтра буде еволюціонувати.
- Проектуйте з урахуванням змін, а не тільки на сьогодні. Завжди запитуйте: «А що, якщо вимоги зміняться наступного місяця?»
- Практика перевершує теорію. Іноді денормалізація та кешування є єдиним способом забезпечити швидку роботу систем.
- Індекси є потужними, але небезпечними. Використовуйте їх обережно.
- Бізнес і відповідність вимогам мають таке ж значення, як і технічний дизайн. Проігноруєте їх, і система впаде в продакшені.
Підсумки
На співбесіді дизайн бази даних має вражати своєю чіткістю.
У реальному житті дизайн бази даних має витримувати зміни, масштабування та хаос.
Перше допоможе вам отримати роботу.
Друге збереже вашу систему в робочому стані о 3-й ночі, коли міграція мільярда рядків піде не так.
І, чесно кажучи, обидві навички цінні.
Одна доводить, що ви вмієте мислити.
Інша доводить, що ви вмієте будувати.
ПРИМІТКА: Поки що це не деталізовано, але незабаром я запущу свій веб-сайт, де ви зможете побачити більше деталей у кращому вигляді. Дякую за терпіння.
З любов’ю: Хіманшу Сінгур
ОРИГІНАЛ СТАТТІ:How We Actually Design Databases in Interviews vs. When Building Real Systems
АВТОР СТАТІ:Himanshu Singour
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
🚀Долучайтесь до нашої спільноти Twiter X:
