This can happen after we do the MVP release.
Evaluate whether to implement a cache mechanism for ongoing events to optimize API performance and reduce database queries.
The evaluation should:
- Talk to someone from old performance team to ask if this cache is really need, and also get recomendations
- Analyze the expected cache size and memory usage
- Determine the optimal cache update frequency (every few hours)
- Design the cache structure and data format
- Plan cache maintenance jobs for removing expired events and participants
- Consider cache invalidation strategies for registration/unregistration events
- Assess the performance benefits vs implementation complexity
BDD
Feature: Cache mechanism for ongoing events
Scenario: Cache size analysis
Given we have data on current active participants and events
When we analyze the expected cache size
Then we determine the memory requirements
And we estimate the cache hit ratio
And we calculate the performance improvement
Scenario: Cache update frequency decision
Given events have varying durations and end times
When we analyze event expiration patterns
Then we determine optimal cache refresh frequency
And we plan cache maintenance job schedule
And we estimate the impact on data freshness
Scenario: Cache invalidation strategy
Given users can register/unregister from events
When a user registers for an ongoing event
Then the cache should be updated immediately
And the user should be added to the cache
Scenario: Cache invalidation on unregistration
Given a user unregisters from an ongoing event
When the unregistration is processed
Then the event should be removed from user's cache
And if no other ongoing events exist, user should be removed from cache
Scenario: Implementation complexity evaluation
Given the cache requirements and design
When we assess implementation complexity
Then we estimate development time
And we identify potential risks and challenges
And we determine if the benefits outweigh the costs
Scenario: Cache maintenance job design
Given the cache needs periodic cleanup
When we design the maintenance job
Then we define the cleanup frequency
And we plan the removal of expired events
And we plan the removal of participants with no ongoing eventssee the rendered diagram on here (if not work copy this diagram code and paste on https://mermaid.live/ ), cache part is on the top right of the diagram, also for reference there is a screenshot in this task of the cache part of the diagram
mermaid
sequenceDiagram
participant U as User
participant MW as MediaWiki
participant FE as Frontend (JS)
participant API as CampaignEvents REST API
participant CACHE as Events Cache
participant DB as Database
participant QUEUE as Message Queue
participant JOB as Background Job
participant Rev as Revision API
participant CACHE_JOB as Cache Maintenance Job
Note over CACHE_JOB,DB: Cache Maintenance (every few hours - check if we need with performance team or if quering i real time is fine)
CACHE_JOB->>DB: Get all participants with ongoing events
DB->>CACHE_JOB: Return participants and events
CACHE_JOB->>CACHE_JOB: Filter out non-ongoing events
CACHE_JOB->>CACHE: Update cache (remove expired events)
CACHE_JOB->>CACHE: Remove participants with no ongoing events
Note over U,DB: User Registration/Unregistration Events
alt User registers for ongoing event
U->>API: Register for event
API->>DB: Save registration
API->>CACHE: Add user to cache with event
else User unregisters from ongoing event
U->>API: Unregister from event
API->>DB: Remove registration
API->>CACHE: Remove event from user cache
alt User has no other ongoing events
API->>CACHE: Remove user from cache
end
end
Note over U,DB: Main Edit Flow
U->>MW: Edit and save article
MW->>MW: Hook EditPage::attemptSave_after
MW->>MW: Set wgPostEdit + revisionId
MW->>FE: Load page with data
FE->>FE: postEdit hook fires
Note over FE,CACHE: Check for ongoing events (API always reads from cache "if we implement it")
FE->>API: GET /rest.php/v1/campaignevents/participant-events?ongoing=true
API->>CACHE: Get user's ongoing events from cache
CACHE->>API: Return cached ongoing events (or empty list)
API->>FE: Return ongoing events list
alt User has ongoing events
FE->>FE: Show custom modal with events
else No ongoing events
FE->>FE: Skip modal (no events available)
end
alt User clicks "Yes" and selects event
FE->>API: POST /rest.php/v1/campaignevents/associate-edit-to-event
Note over FE,API: {revisionId: 123, wikiId: "ptwiki", event_id: 1, timestamp: "2024-01-01T10:00:00Z"}
API->>CACHE: Validate user has ongoing event in cache
CACHE->>API: Confirm user participation and event status
API->>API: Validate event is still ongoing (within time window)
alt Event is ongoing and user is participant
API->>QUEUE: Send message to queue
Note over QUEUE: {revisionId, wikiId, eventId, userId, timestamp}
API->>FE: Return success (queued for processing)
FE->>U: Show "Processing" notification <br>(Like event data will be avaliable soon on contributtions tab)
else Event ended or user not participant
API->>FE: Return error (invalid event/participation)
FE->>U: Show error message
end
else User clicks "No"
FE->>U: Close modal
end
Note over JOB,DB: Background processing (asynchronous)
JOB->>QUEUE: Process queued messages
JOB->>Rev: Get current revision (revisionId)
JOB->>Rev: Get previous revision
Rev->>JOB: Return revision contents
JOB->>JOB: Calculate differences
Note over JOB: - Bytes added/removed<br/>- Characters added/removed<br/>- Internal links<br/>- If new article
JOB->>DB: Save to ce_associate_edit_to_event
Note over DB: {eventId, revisionId, userId, wikiId,<br/>bytesAdded, bytesRemoved, charsAdded,<br/>charsRemoved, timestamp, isNewArticle,<br/>linksAdded}