Page Comparison

[DRAFT]

Spike Overview

User Story: https://folio-org.atlassian.net/browse/EUREKA-211 Spike - Revisit routing of mod-scheduler requests

...

Resolving this gap is crucial for ensuring that the Sidecars always have up-to-date routing information, especially in a dynamic multi-tenant environment where entitlements may change frequently.

Option 3.4

...

1. Reduced System Complexity: By eliminating the mgr-discovery component and integrating its functionality into the Sidecar, the overall system architecture is simplified. This reduces the need for external dependencies and minimizes potential points of failure.

2. Centralized Routing Logic: The Sidecar now handles all aspects of routing, including dynamic route resolution and caching, reducing the need for multiple components and simplifying management.

3. Improved Performance: The internal route cache with an expiration policy allows the Sidecar to quickly resolve frequently used routes, reducing the latency associated with querying external components repeatedly.

4. Greater Autonomy for Sidecars: Each Sidecar becomes more self-sufficient, handling route discovery and caching independently, which can make the system more scalable and less reliant on centralized routing services.

5. Easier Maintenance: With fewer moving parts (no need for a separate mgr-discovery component), maintaining and troubleshooting the system becomes easier, with a more focused logic inside the Sidecar.

Cons:

1. Increased Sidecar Complexity: By integrating route discovery and caching functionalities into the Sidecar, the component becomes more complex to develop, maintain, and debug. This increased complexity could lead to longer development cycles and more potential bugs.

2. Higher Memory and Resource Usage: The Sidecar now stores route information in a cache, potentially increasing its memory footprint. For systems with many routes, this could require more memory and CPU resources to manage effectively.

3. Potential Cache Staleness: While the cache has an expiration policy, there is still a risk that the route information could become outdated before the cache refreshes. This could lead to routing errors until the cache is updated.

4. Lack of Centralized Route Management: Since each Sidecar now independently handles route discovery, ensuring consistency across different instances of Sidecars could be more challenging, especially in multi-tenant environments.

5. Greater Dependency on Sidecar Robustness: The Sidecar becomes a critical point of failure. If a Sidecar encounters an issue, routing could be disrupted for that particular service, affecting its ability to process requests effectively.

6. Potential Latency from Cache Expiration: When the cache expires, the Sidecar needs to query external modules to refresh routing information. This could introduce additional latency during cache refreshes, particularly in high-traffic deployments.

Conclusion

During several rounds of discussion, option 3.4 was selected because it best suits the requirements. We’d like to consolidate the mechanisms used by the sidecars to obtain discovery information.

Spike Status: