Skip to content

0014: Handling uncapping in Adgem

STATUS

Accepted

CONTEXT

Currently, the Adgem dashboard has a scheduled artisan command that runs at the beginning of each day and uncaps all campaigns. We would like to improve how uncapping is handled. The ADR here proposes a solution for handling flexible capping wherein capped campaigns will have a capped_until value set for them. This current ADR attempts to answer the question: how should we update the campaign_capped field (based on the capped_until field)? Or should we deprecate the campaign_capped field and replace all its uses to instead rely on capped_until.

Considered Options

  1. scheduled artisan command that regularly checks for campaigns that need to be uncapped
  2. airflow job that finds campaigns that are capped (campaign_capped is true) and need to be uncapped (current_date > capped_until) and makes an api call to the new_dashboard to uncap them
  3. deprecate the campaign_capped field. Anywhere that needs to check that field will instead compare the current time to the capped_until value.
  4. instead of having a capped_until column in the campaigns table, we could create a new table campaign_caps that would track campaign caps. This would provide a more robust solution that would allow us to support multiple caps on a single campaign.

DECISION

Options 1 and 3 are both good. Since there are many different areas of the code to clean up in order to accomplish Option 3, my recommendation is to start with option 1. That should be a very light lift, and will allow us to start building out the rest of the capping logic. We can add a tech debt item to our backlog to a) transition all uses of the campaign_capped field over to use capped_until, and b) remove the scheduled artisan command.

Below is a deeper dive into each option.

Option 4

Option 4 is not a worthwhile investment right now. Because of how we handle caps, multiple caps on a single campaign would not be valuable. See this wiki.

Option 2

Option 2 moves the processing to airflow. This is consistent with how we do flexible capping (see this ADR), but it's unnecessary to do this in airflow since all the data we need is already in the adgem db.

Option 1

Option 1 is a good solution, and also the simplest. It adds additional some overhead to the production new_dashboard server, but this should be fairly minimal. All the data needed is contained within the Adgem DB, so there's no need to load data from the Redshift data warehouse.

Option 3

Option 3 is do-able, but a bigger lift because it would involve updating any uses of the campaign_capped field (across new_dashboard and api) to instead use capped_until. In practice, this would likely be implemented by adding an Attribute and a Query Scope to the Common/Campaign model.

Below are the uses across the api and new_dashboard projects: - api - CampaignDataAccessor@findStaticOfferwallCampaigns (DB::query) - CampaignDataAccessor@buildBaseOfferwallQuery (DB::query) - CappedCampaign@handle (reading campaign_capped property value) - prevents players from starting an offer for a capped campaign (endpoint middleware redirecting /click and /offer-insterstitial to error page if campaign is capped) - tests - new_dashboard - CapCampaigns - scheduled artisan command; will be deprecated by the flexible capping feature anyway, so no extra work here - SendCapCampaignsEmail@getTodaysCappedCampaigns (Eloquent query) - CampaignsController@toggedCappedCampaign (sets campaign_capped to false) - AppCampaign@scopeBasicCampaignFilters (Eloquent query) - query scope to find active app_campaigns - CampaignViewModel@createFromCampaign (sets view-model value based on campaign's property's value) - tests

CONSEQUENCES

  • as mentioned above, starting with Option 1 introduces the tech debt of having two fields that handle capping: campaign_capped and capped_until. This has the potential of causing confusion. In the future, we'll want to go back and transition all functionality over to using the capped_until field and then deprecate the campaign_capped field.

Risks

NOTES

References

Original Author

Dylan Kreth

Approval date

Nov 22, 2024

Approved by

Ron White, Ben Giese

Appendix