В вашем последнем проекте с микросервисами использовалась ли общая база данных?

Нет, в соответствии с принципами микросервисной архитектуры, каждый сервис обладал собственной, изолированной базой данных (Database per Service).

Причины и преимущества такого подхода:

1. Независимость и слабая связность: Сервисы не зависят от внутренней схемы данных друг друга. Изменения в одной БД не ломают другие сервисы.
2. Выбор оптимальной СУБД: Каждый сервис может использовать наиболее подходящую технологию (например, PostgreSQL для транзакций, MongoDB для документов, Redis для кэша).
3. Масштабируемость: Базы данных можно масштабировать независимо в соответствии с нагрузкой на конкретный сервис.
4. Четкие границы владения: Команда сервиса полностью контролирует свою модель данных и миграции.

Пример разделения:

// Сервис заказов (Order Service)
@Service
public class OrderService {
    @Autowired
    private OrderRepository orderRepository; // Работает ТОЛЬКО с БД заказов
}

// Сервис оплат (Payment Service)
@Service
public class PaymentService {
    @Autowired
    private PaymentRepository paymentRepository; // Работает ТОЛЬКО с БД платежей
}

Синхронизация данных между сервисами осуществляется не через общую БД, а через:

• Асинхронные события (Kafka, RabbitMQ) для eventual consistency.
• Синхронные API вызовы (REST/gRPC) там, где требуется строгая согласованность.