Andrey-2

Если у вас есть возможность работать с планировщиком задач (шедуллер), то все и будет просиходть ровным счетом как вы описали. Вы используете технику webhook. То есть, обычно внешний сервис (если мы говорим о микросервисах) дает потребителю свой адрес, на который он ожидает запросы и так же он требует обратный адрес потребителя. Куда слать ответы. В вашем случае у вас оба "сервиса" ваши. Так что просто предоставьте друг другу адрес для запроса и для ответа.
Примерный сценарий.
1) Единственное действие пользователя - отправить список айдишников. Сервис 1 вызывает вебхук-запроса.
2) Сервис 2, принимает запрос, и шлет сразу ответ на предоставленный ему адрес для ответов. Ок или не Ок.
3) Сервис 1 получает ответ и обрабатывает (ожидание или retry).
4) В какой-то момент Сервис 2 начианет слать ответы в сервис 1 по преодоставленному вебхук-ответу.
5) Сервис 1, так же через планировщик мониторит базу ну и делает оставшуюся работу.

Как-то так

Как бы ты не изворачивался, либо у тебя получится поддержка только подмножества веб приложений (и очень не эффективное) либо очередной браузер, но зачем, когда есть готовые.

Подключаешь к проекту какой-нибудь браузер, открываешь требуемую ссылку там, мониторишь итог на предмет окончания загрузки (отдельная проблема)...
например штатный компонент .net WebBrowser это древний internetexplorer11 на windows, но при запуске проекта на mono - это будет что то основанное на firefox

этот вариант будет иметь наивысшую производительность, наверное даже лучше selenium, так как это не отдельный браузер а только библиотека с кастрированным функционалом, но не на много (грубо говоря нет поддержки расширений, работы с камерами, уведомлениями и т.п.), так же такой способ проще детектировать со стороны веб приложения, которое борется с автоматизациями