User Group Consistency and Refresh Framework

This document describes the approach for keeping dynamic user groups up-to-date based on changing user data and criteria. It covers different update methods, event-based, scheduled, and manual, as well as how to handle inconsistencies, stale data, and mutually exclusive criteria.

The goal is to ensure group membership remains consistent and predictable while allowing flexibility in how updates are triggered and managed.

1. Update Methods

Group updates can happen through different mechanisms depending on the nature of the criteria and the system's capabilities:

• Event-based: Triggered automatically when a relevant system event occurs (e.g. user changes enrollment track). Use this approach when possible.

• Scheduled (by frequency): Triggered at regular intervals, defined by each criterion or group (TBD). See proposed frecuencies updates here: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4934664196/WIP+MVP+Requirements+User+Group+Creation+and+Management+for+Courses#User-Group-Management

• Manual: Triggered by an operator as needed.

Groups may rely on one or more of these methods, and auxiliary mechanisms can be used to reduce temporary inconsistencies (e.g. a user moved to a new group may be removed from a conflicting one immediately).

2. Refresh Frequency and Staleness

• Refresh frequency is defined per criterion and determines how often the group should be re-evaluated. It can be overridden for operational reasons.

• Staleness is a property of a group, defined by the shortest staleness value of its criteria. It is primarily used to signal when a manual update may be needed.

Staleness and refresh frequency are related but separate concepts. A group may not be considered stale even if it hasn't been updated recently, as long as it is within its expected refresh window.

If a group's frequency is set to 7 days, a background task will trigger an async update after 7 days from the last sync. This re-evaluates the criteria over the users in the group's scope.

3. Handling Mutual Exclusivity (TBD as requirement)

If a user is assigned to a group based on criteria C₀, ..., Cₙ₋₁, and a subset of these (Cₐ, ..., Cₕ) are mutually exclusive, the user should be removed from any other group that uses any of the mutually exclusive criteria.

This can be enforced at assignment time or via event-based logic, depending on whether the system has access to the relevant data. This helps avoid inconsistent states, such as being in two groups that should never overlap.

4. Inconsistencies and Overlap Handling

Inconsistencies can happen when groups are updated on different schedules or depend on third-party data.

Example:

• G1: Users who live in Spain (updated weekly, created today)

• G2: Users who live in Portugal (updated weekly, created 4 days later)

If Majo moves to Portugal and updates her profile 3 days after G1 is created, she may temporarily appear in both groups. This could result in showing conflicting content.

Proposed solution:

• If system events align with group criteria, use event-based updates to handle the change in near real-time.

• If not, remove the user from conflicting groups manually or during assignment to ensure consistency.

5. Mixed Update Method Considerations

Would it be a problem to mix multiple update methods? Consider the previous example:

• G1: Users who live in Spain (updated weekly)

• G2: Users who live in Portugal (updated weekly)

Suppose Majo updates her country and an event-based update moves her from G1 to G2 immediately. In that case, does the weekly update still need to run? If event-based updates are reliable (triggered after DB commits), scheduled updates may become redundant?

Still, scheduled syncs can be useful:

• As a fallback if an event is missed or not implemented

• For criteria based on external data sources where events are not available

• For long-term correction of inconsistencies

To avoid unpredictable group assignments, we should define a clear priority:

• Prefer event-based updates when available

• Use scheduled updates as a fallback for eventual consistency

• Restrict certain criteria to one update method if needed

6. Proposed Rules

• Use event-based updates whenever possible

• Remove users from conflicting groups at assignment time

• Treat scheduled syncs as fallback mechanisms

• Trigger all syncs for a given scope at the same time

• Accept some temporary inconsistencies when data is delayed or external

• Define update priority to avoid conflicts between methods