Для разных БД и так будут разные пулы соединений, их просто не получится объединить в один. Речь конечно же о варианте с двумя пулами для одной БД.
Например, есть у вас сервис по обработке заказов. У него есть методы для создания заказа и изменения его состояния (подтвержден, завершен, отменён), а также методы для получения информации о заказе (подробности заказа, история). Первые являются бизнес-критичными, а вторыми можно пожертвовать в случае отказа, компания не потеряет деньги. Разделив соединения к БД заказов на два пула мы можем выделять ресурсы (соединения) независимо, и если внезапно возрастёт нагрузка на методы получения данных о заказах, это не приведёт к замедлению или остановке обработки заказов.
Теоретически можно выделить отдельный слейв БД только для чтения, а обработку заказов делать на мастере, но в реальности возникают ситуации, когда необходимо сразу после обновления считывать свежие данные, а лаг репликации препятствует этому. Также в БД могут храниться другие данные, необходимые для обработки заказа (например инфо о клиенте), которые будут читаться со слейва, и эти операции тоже должны быть защищены от повышенной нагрузки на некритичных методах. Тем самым выделение read-only слейва уже не спасёт, и потребуется применять паттерн Bulkhead.
Мысль интересная, я возьму на заметку. Во фреймворки для AI я ещё пока не погружался.
Для разных БД и так будут разные пулы соединений, их просто не получится объединить в один. Речь конечно же о варианте с двумя пулами для одной БД.
Например, есть у вас сервис по обработке заказов. У него есть методы для создания заказа и изменения его состояния (подтвержден, завершен, отменён), а также методы для получения информации о заказе (подробности заказа, история). Первые являются бизнес-критичными, а вторыми можно пожертвовать в случае отказа, компания не потеряет деньги.
Разделив соединения к БД заказов на два пула мы можем выделять ресурсы (соединения) независимо, и если внезапно возрастёт нагрузка на методы получения данных о заказах, это не приведёт к замедлению или остановке обработки заказов.
Теоретически можно выделить отдельный слейв БД только для чтения, а обработку заказов делать на мастере, но в реальности возникают ситуации, когда необходимо сразу после обновления считывать свежие данные, а лаг репликации препятствует этому. Также в БД могут храниться другие данные, необходимые для обработки заказа (например инфо о клиенте), которые будут читаться со слейва, и эти операции тоже должны быть защищены от повышенной нагрузки на некритичных методах. Тем самым выделение read-only слейва уже не спасёт, и потребуется применять паттерн Bulkhead.