...
The main idea is to work in detail on option 3, described in the EUREKA-89 Spike - Design solution for scheduled system calls.
There are two three possible solutions here, but both all of them originate from the same ideas: mgr-applications and mgr-tenant-entitlements contain all the information to identify a correct route that should be used for a particular “timer call” from the mod-scheduler. So, these “timer“ routes should not be configured in Kong, and all the discovery information could be retrieved dynamically or available when it is needed.
Option 3.1
...
The following diagram displays the main components and actors involved in the flow.
| Drawio | ||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
This option introduces a new component, mgr-discovery, that acts as a facade for the Sidecars and provides a single point of interaction between Them them and the mgr-* components. Sidecar will use mgr-discovery to read all bootstrap info related to the FOLIO module the Sidecar serves and dynamically retrieve discovery information that will be used for timer routings.
...
Multiple ways for sidecars to get discovery information when “Dynamic Routing“ is enabled.
Multiple modules for dynamic routing resolution increase the overall complexity of the system.
Dynamic routing can potentially introduce additional latency due to the extra steps required to resolve discovery info. The usage of the cache should mitigate the issue.
mgr-discovery becomes a critical component. if it fails, it could disrupt the entire routing and bootstrapping mechanism. HA and redundancy should be used to mitigate this.
Option 3.2
...
.
...