Как реализовать микросервис телефонной очереди с точки архитектуры?

Question

[3ton]

Необходимо создать микросервис телефонной очереди(например к психологу).

Дается
- все звонки в очереди запланированы как исходящие
- в очереди звонки могут быть двух типов 1) на запланированное время; 2) в виде живой очереди
- между звонками должна быть пауза к примеру 5 минут
- максимальная консультация 30 мин ,после чего звонок прерывается

Для лучшего понимания приведу пример:
Консультант1 и консультант2, а так же с десяток клиентов.

У консультанта1 запланированы консультации с клиент1 (10:00), клиент2 (11:00), клиент3 (13:30), клиент4 (14:30), клиент5 (15:30)

У консультанта1 запланированы консультации с клиент6 (9:00), клиент7 (10:00), клиент8 (11:00), клиент9 (14:00), клиент10 (15:00)

Кроме того есть часть клиентов желают связаться без записи, в качестве живой очереди.

Чтоб оптимизировать время консультаций берем за основу что консультанту нужно 5 минут перерыва между полноценными консультациями клиентов.

Потому к примеру у консультанта1 до первой записи можно будет принять 2 звонка, но возможно их вопросы пустяковые или сразу же обнаружится что вопрос по части другого специалиста и тогда очередь сразу же должна обновиться и микросервис должен пропустить к консультации следующего клиента из живой очереди при условии что до запланированной в расписании следующей консультации должно быть не менее 20 минут.

на ум приходит 2 варианта реализации
I вариант- скриптовый (к примеру PHP)
Все заявки содержаться в таблице базы данных и при каждом запросе на консультацию совершается пробег по имеющемуся расписанию и ежели это
- запланированная консультация и время между другими запланированными позволяет ее вместить, то вносим ее на запрошенное время
- в порядке живой очереди, то фиксируем ее как живую очередь без запланированного времени старта
Далее у нас создается либо скрипт который будет раз в минуту(по крону), либо в цикле с паузами в 10-30 сек пробегать по таблице очереди и формировать команду на телефонию для создания телефонного соединения. Ежели связь не удалась, делается пауза 30 сек и снова попытка, после чего заказ маркируется как обваленый переходим к следующему.

II - делается демон которые крутится под linux
Все данные так же или в другом виде содержатся в базе, либо же в чем то более оперативном типа redis
Демон пишется на Go, Ruby, NodeJS или др. (зависит от возможности языка без танцев с бубном общаться с Asteris/Freeswitch). Каждая консультация в демоне как отдельный объект в пуле консультаций, в случае если консультация истекла либо обвалилась - вызывается метод ее завершения который в свою очередь должен запланировать резервирование консультанта и через 5 минут запустить запрос на телефонию. Следовательно в пуле каждого консультанта может быть очередь из нескольких консультаций и только одна может быть активной на любой момент времени. а следующая запускается не как в первом варианте пробегом скрипта по таблице, а запланированным временем старта самого объекта консультации.

Для живой очереди существуют следующие правила
- ежели после окончания консультации есть живая очередь и до следующей запланированной промежуток более 20 мин, то мы ее запускаем ,иначе мы запустим ее после окончания следующей запланированной, снова проверив свободное время до следующей запланированной.
- ежели течет консультация из живой очереди и подходит время запланированной, то оба собеседника получать уведомляющий сигнал за несколько минут до прерывания консультации и за 5 минут до старта запланированной консультации, текущая из живой очереди будет прервана

Хочется понять плюсы и минусы выбранных путей реализации, а так же возможно более оптимальные решения для данной задачи в плане надежности и стабильности работы в режиме нонстоп и обновления микросервиса.