Options for Running Multiple Versions of the Same Module on the EUREKA Platform

1 Option 1 – Topic consolidation with selective environment isolation
- 1.1 Example topic names
- 1.2 Important requirements
- 1.3 Limitation
2 Option 2 – Consumer-Level Tenant Filtering (EUREKA Components Implementation)
3 Option 3 – Full Tenant Entitlement-Based Filtering
4 Option 4 – Dedicated Kafka for EUREKA components

Below is a list of possible approaches for supporting multiple versions of the same module within the EUREKA platform.

Option 1 – Topic consolidation with selective environment isolation

Continue using topic consolidation, but isolate the new module version via a separate environment value while keeping the platform on a single shared environment.

Keep the EUREKA platform and all sidecars on the same ENV (for example, ENV=folio).
For the old version of modules, use a dedicated ENV value (for example, ENV=ramsons).
For the new version of a specific module, assign a different ENV value (for example, ENV=sunflower) for its producer and consumer.
This allows the new version to use its own set of Kafka topics, while the rest of the platform continues to use the original environment.

Example topic names

Old environment (existing modules):

ramsons.all.mod-inventory-storage.instance
ramsons.all.mod-audit.events

New environment (new module version):

sunflower.all.mod-inventory-storage.instance
sunflower.all.mod-audit.events

Important requirements

The sidecar’s ENV must always match the EUREKA platform (for example, ENV=folio).
Only the modules (producer/consumer) are allowed to move to a different ENV for topic isolation; sidecars must remain aligned with the platform environment.
Some modules from the application platform minimal are part of EUREKA and must always run with ENV=folio.

Limitation

Running multiple versions of the platform-minimal application in the same EUREKA environment is not supported. To run multiple versions of these core components, you must:

Isolate them by ENV, and
Run multiple EUREKA environments (one per version).

Option 2 – Consumer-Level Tenant Filtering (EUREKA Components Implementation)

Quickly add logic to Kafka consumers so they skip messages for tenants that are not entitled to a given module.

This applies to modules such as:

mod-login-keycloak
mod-roles-keycloak
mod-scheduler

This approach makes it possible to run multiple versions of the platform-minimal application, while keeping the existing REST-based behavior unchanged.

Option 3 – Full Tenant Entitlement-Based Filtering

Once all modules support tenant-based filtering:

Consumers process messages only for tenants where the module is entitled.
All modules share the same ENV environment variable.
Topic isolation is handled logically at the consumer level rather than by environment separation.

This approach provides a cleaner, long-term solution; however, it requires changes to shared libraries. All modules that interact with Kafka must be updated to use the new version of the library in order to implement tenant entitlement–based message filtering consistently.

Option 4 – Dedicated Kafka for EUREKA components

During the meeting where we discussed options for running multiple versions of the same application, we also considered running a dedicated Kafka cluster for EUREKA modules to isolate topics per version.

However, further analysis showed that splitting Kafka only for EUREKA components would not resolve the issue. Core services such as mgr-entitlements, mgr-tenants, and all sidecars still need to share the same Kafka cluster in order to communicate correctly. In addition, key platform-minimal components like mod-roles-keycloak, mod-users-keycloak, and mod-scheduler must remain on that same Kafka as well.

As a result, it is not possible to cleanly isolate multiple versions of the platform-minimal stack via a dedicated Kafka for EUREKA, and we would continue to experience the same multi-version conflicts.