Проверяет понимание архитектурных подходов к хранению данных в микросервисах и умение выбирать между ними по критериям согласованности, связанности и масштабируемости.
Хранение данных в микросервисах — один из ключевых архитектурных вопросов, потому что от него зависит, насколько сервисы действительно независимы. Если сервисы делят одну базу, они неявно связаны через схему и транзакции, и любое изменение таблицы ломает соседей. Поэтому в зрелых системах обычно стремятся к изоляции данных.
// Псевдокод оркестратора заказа
async function createOrder(order) {
const payment = await paymentService.charge(order);
if (!payment.ok) return fail('payment');
const stock = await stockService.reserve(order);
if (!stock.ok) {
await paymentService.refund(payment.id); // компенсация
return fail('stock');
}
return { status: 'confirmed' };
}Если система небольшая и команда одна — shared database допустима как временное решение. Для крупных распределённых систем с независимыми командами выбирают database per service и Saga. CQRS применяют там, где нагрузка на чтение сильно превышает запись или нужен полный аудит изменений.
Итог: применяйте database per service и Saga, когда важны автономия сервисов и масштабируемость; shared database оправдана только на ранних этапах или в монолитных по сути системах.
