misc(usage): Scope usage caching to the charge filter level #2678
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vincent-pochet
force-pushed
the
misc-filter-caching
branch
from
5a8494a to
9f957be
Compare
vincent-pochet
force-pushed
the
misc-filter-caching
branch
from
9f957be to
5bf0ea2
Compare
vincent-pochet
added a commit
that referenced
this pull request
Oct 25, 2024
## Context This PR is related to #2678. The charge filter lookup that was added in the `Events::PostProcessService` lead to some performance regression. The reason behind this is that the `ChargeFilters::EventMatchingService` is reloading systematically the charge filters and associated values even if they were already pre-loaded in the `Events::PostProcessService` ## Description The PR is checking the cached status of the `filters` association to avoid the reload.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Today caching for usage data is scope to the charge.
When an event is received for a specific billable metric code will invalidate the cache for all charges attached to it for the customer's plan. The cache will leave until the end of the billing period or until a new event is received for the same billable metric code and subscription.
This logic avoid recomputing the complete charge aggregation every time the customer usage is requested.
This logic was fine until the introduction of charge filters.
Aggregation for filters are done one by one for every filter, and stored in cache using the same charge cache key (ie: all filtered aggregations are grouped inside the same charge cached bucket). When an event matching a filter is received it invalidate the cache for all filters, meaning that when fetching the usage we have to resegregate it for every single filter even if nothing new was received for the majority of them.
Description
This PR refactors some parts of the usage computation and adds a new caching logic to scope the caching up to the charge filter when applicable and keeping the actual caching when no filters are attached to the charge.