Page MenuHomePhabricator

Evaluate and decide on cache implementation for ongoing events
Open, Needs TriagePublic

Description

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 events

see 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

Screenshot 2025-08-06 at 14.34.37.png (759×1 px, 128 KB)

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}

Event Timeline

My understanding is that we would not adopt any caching strategy for the time being, and will re-evaluate later; and that's based on early conversation in T401207. So, should we close this task?

ifried updated the task description. (Show Details)

Moving to upcoming because we will assess next steps for this ticket after the MVP release.