Як масштабування впливає на консистентність даних?

Масштабування напряму впливає на консистентність даних, бо за розподілу даних між серверами стає складніше гарантувати, що всі вузли бачать однаковий стан бази в один і той самий момент.

#1. Вертикальне масштабування

• Дані розташовані на одному сервері, тому консистентність зберігається автоматично - транзакції працюють у межах однієї СУБД.
• Проблем з узгодженістю майже немає, але є фізична межа зростання.

Підсумок: консистентність висока, але масштаб обмежений.

#2. Горизонтальне масштабування (реплікація, шардування)

Коли дані розподіляються між кількома вузлами, з'являються нові ризики:

а) Затримки реплікації. За асинхронної реплікації зміни на master доходять до реплік із затримкою. У результаті різні вузли можуть містити різні версії даних. Приклад: користувач робить замовлення - на master воно вже створене, а на репліці його поки немає.

б) Розподілені транзакції. За шардування одна операція може зачіпати кілька серверів. Щоб зберегти атомарність, потрібна координація (наприклад, протокол two-phase commit), але це збільшує затримки й ризик помилок.

в) CAP-теорема. У розподілених системах не можна одночасно забезпечити:

• Consistency (узгодженість),
• Availability (доступність),
• Partition tolerance (стійкість до збоїв мережі). Масштабовані системи зазвичай жертвують суворою консистентністю заради доступності й швидкості.

#3. Компроміси на практиці

• Більшість систем обирають модель eventual consistency - дані тимчасово можуть відрізнятися, але з часом вирівнюються.
• Для критичних операцій (гроші, транзакції) використовують синхронні механізми, жертвуючи швидкістю заради точності.

Підсумок: Чим сильніше система масштабується горизонтально, тим складніше зберігати ідеальну консистентність. Тому архітектори обирають баланс - між швидкістю, надійністю й точністю даних.