На soсket надо кинуть сообщение и там его обработать. Можно либо кидать сообщение на конкретный socket, но тогда надо знать кому его кидать.
Нужно сделать общую шину - с обработчика POST - кидать уведомление, в soсket - подписаться на уведомление.
Ильдар Гизетдинов, Ну, если событие асинхронное и может занять длительное время и их надо выполнять независимо от других - тогда очереди лучше решение чем RPC.
Но придется работать с callback-очередями. Можно поискать RPC на основании очередей - я такое делал. Для клиентского кода вызов выглядит как синхронный, хотя под капотом там работают очереди.
Вообще контекст задачи не совсем ясен, потому больше нечего мне добавить
blabs, понятней не стало.
Какого рода запросы? Можно ли их делать в фоне в наименее нагруженное время? Можно ли их кешировать ? Можно ли оптимизировать запросы? И т. д. Синхронизация данных между разными типами баз данных - весьма геморное занятие. Это уже должен быть крайний шаг, если ничего другого нельзя придумать. И с этим придется жить долго и нудно.
В общем в вопросе мало конкретики.
Синхронизация возможна несколькими путями, например :
0. Запись в базу данных осуществляется через 1 адаптер - он уже записывает данные в две базы - непонятно что делать если в одну записалось, а в другую - нет.
1. Аналогично предыдущему, но через очереди. Проблема та же + работа с очередью.
2. Отправка запроса из Postgresql на другую базу в тригере (через очередь, через прокси-сервис) и т. п. Не знаю, позволяет ли это сделать база данных (PG). Для mysql есть решения, которые позволяют отправлять http запросы, но там есть косяк в тригерах - срабатывает даже если транзакция откатилась - не знаю важно ли это и может уже и пофиксили.
В общем - варианты есть. Но надо основательно взвесить все против.
upd:
3 * 15 - 45 миллионов записей в месяц ((3 + (0,1 × 12 × 5))× 15 = 135 млн в месяц через 5 лет при указанном приросте). При правильном подходе - вообще не проблема. Можно писать в отдельные таблицы, например по дням, по месяцам...
kornylovamargarita, скорее всего проблема в том, что подмена атрибутов не сработала.
в `soap` при создании клиента можно передать еще опцию `endpoint`, которая переопределит куда обращаться, может это поможет?