Может ли сервис продолжать работу, если база данных становится недоступной?

Да, но с ограниченной функциональностью, если архитектура спроектирована для устойчивости к отказам (fault tolerance). Простой монолитный сервис, напрямую зависящий от БД, скорее всего, упадёт.

Стратегии для обеспечения работы при недоступности БД:

1. Кэширование (Cache-Aside Pattern): Сервис может обслуживать запросы на чтение из кэша (например, Redis).

   @Cacheable(value = "users", unless = "#result == null")
   public User getUser(Long id) {
       // При недоступности БД метод выбросит исключение,
       // но предыдущие закэшированные данные останутся доступны.
       return userRepository.findById(id).orElse(null);
   }

2. Асинхронная запись и очереди: Операции записи помещаются в надёжную очередь (Kafka, RabbitMQ) и обрабатываются позже, когда БД восстановится.
3. Circuit Breaker (Автоматический выключатель): Паттерн, предотвращающий лавину запросов к неработающей БД.

   // Используя Resilience4j
   @CircuitBreaker(name = "databaseService", fallbackMethod = "fallbackResponse")
   public Data getData() {
       return dbCall(); // Вызов к БД
   }

4. Репликация и read-only реплики: Направление запросов на чтение к репликам, если основная БД недоступна.

Вывод: Работа при сбое БД требует архитектурных решений: кэши, очереди, механизмы graceful degradation.