This document aims to detail how synchronization between the new unified user grouping system (User Groups) and the existing grouping mechanisms (Legacy Groups) will be managed to ensure a successful transition in the https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4955668482/Cross-System+Synchronization+Proposal?atlOrigin=eyJpIjoiNDQ5ZGI4MTE4M2FjNGI5NWE5YjFmNjllY2RjYTdkYzQiLCJwIjoiYyJ9. Two different approaches are proposed, one more straightforward than the other. The first is a unidirectional approach, and the second is a bidirectional approach.

NOTE: User Groups refers to the new unified user grouping system. Legacy Groups refers to the current grouping mechanisms (Enrollment Track Groups, Cohorts, and Teams).

Unidirectional Approach

This approach only ensures synchronization from the User Group → Legacy Group. That is, all changes made in the User Groups will be reflected in real time in the corresponding Legacy Groups.

User Group → Legacy Group

Synchronization will be performed via the Evaluators. All User Groups that use criteria associated with a Legacy-type evaluator will have the ID of the corresponding Legacy Group, allowing the system to identify which Legacy Group the User Group is linked to. The ID will be stored in the criteria configuration

The Legacy Group evaluators will handle the following operations:

• POST: When a User Group is created, the necessary data will be used to create a corresponding Legacy Group. The User Group will then be linked to the Legacy Group via its ID.

• GET: The evaluator will fetch data from the Legacy Group, update it in the User Group, and return it.

• PUT/PATCH: Updates the data in the Legacy Group, and then update the data in the User Group.

• DELETE: Deleting the associated Legacy Group and then deleting the User Group. Problem: Not all Legacy Groups can be deleted. For example:

  • Enrollment Track Groups cannot be deleted.

  • Cohorts cannot be deleted.

Any error from the Legacy Groups must be captured and properly handled to prevent any kind of inconsistencies in the User Groups.

By default, with this approach, the User Group becomes outdated compared to the Legacy Group. The only way to resync it would be to trigger a manual or programmatic refresh.

Bidirectional Approach

This approach, like the previous one, ensures synchronization from User Group → Legacy Group, but also requires synchronization in the opposite direction: Legacy Group → User Group.

Legacy Group → User Group

This would use an event-based synchronization strategy. CRUD actions would emit Open edX Events (or add them if they don’t already exist), which would then trigger all the necessary logic to replicate the changes in the corresponding User Groups in real time.

Advantages & Disadvantages

Unidirectional Approach (User Group → Legacy Group)

Advantages:

• Simple to implement, since it doesn’t require changes to the legacy systems (Cohorts, Teams, Enrollment Tracks).

• Reduces workload by handling all sync logic within the new system's evaluators.

• Lower risk, as it avoids interfering with legacy models and APIs.

Disadvantages:

• Legacy groups may become outdated if they’re edited manually outside the user group system.

• Synchronization is only one-way; inconsistencies may arise unless user groups are refreshed.

• No real-time sync from legacy to user groups.

Bidirectional Approach (User Group ↔ Legacy Group)

Advantages:

• Ensures real-time consistency between the user group system and legacy groups.

• Supports updates from either side. Changes in legacy groups are reflected in user groups and vice versa.

• Provides greater transparency and synchronization reliability.

Disadvantages:

• Requires technical changes to legacy systems, including new events or signals.

• Increases complexity, with higher chances of bugs or unintended behavior.

• More expensive to develop and maintain over time.

• Relies on full event coverage in legacy systems, which might not be complete.

Open Question: What is the best approach?