I started a document for discussion.

I think the main open question is if the additional database table, its proposed columns, and usage is acceptable to DBA, so I'm tagging you all to ask for comments specifically on the "Storage" section of the document.

Generally I don't see an issue with the proposal, what has been bothering me about it is the daily cron and maint script and the general plan of migrating to the data gateway while directly using it inside mediawiki.

Let me explain it further. What we currently have is links recommendation system that seems to be decoupled from mediawiki's database and looks nice and all ("modern") but actually, it depends on the core's database. We have a cron that daily updates those values from the service and put it in mediawiki's database which basically defies the whole point of having them in the first place and have been causing a lot of maintenance headache for DBAs doing maintenance of mediawiki databases: T299021: Reduce running time of refreshLinkRecommendations.php to a maximum of 60 minutes (including prolonging several schema changes because the first run failed, etc.)

I was told that these Frankenstein system is temporary but it has been temporary for way too long and I don't think it's wise to add even more cases to it. We should either decide and get it delivered before adding more or design it without keeping data gateway in mind.

In T309747#8029702, @Ladsgroup wrote:

Generally I don't see an issue with the proposal, what has been bothering me about it is the daily cron and maint script and the general plan of migrating to the data gateway while directly using it inside mediawiki.

Let me explain it further. What we currently have is links recommendation system that seems to be decoupled from mediawiki's database and looks nice and all ("modern") but actually, it depends on the core's database. We have a cron that daily updates those values from the service and put it in mediawiki's database which basically defies the whole point of having them in the first place and have been causing a lot of maintenance headache for DBAs doing maintenance of mediawiki databases: T299021: Reduce running time of refreshLinkRecommendations.php to a maximum of 60 minutes (including prolonging several schema changes because the first run failed, etc.)

FWIW, we consulted with SRE + DBA teams when planning the Add Link project (see Add_Link#Updates) when figuring out the architecture. Moving the caching layer into the Link Recommendation service (as opposed to MW tables) is perfectly fine, but a separate discussion. If you'd like for us to consider that, let's make a task for it.

I was told that these Frankenstein system is temporary but it has been temporary for way too long and I don't think it's wise to add even more cases to it. We should either decide and get it delivered before adding more or design it without keeping data gateway in mind.

This sounds like a separate concern, although there are some similarities in the setup proposed. The main difference is that if we use the data gateway, we will use that exclusively for storage and not make any writes to MediaWiki database tables.

In T309747#8045294, @kostajh wrote:

In T309747#8029702, @Ladsgroup wrote:

Generally I don't see an issue with the proposal, what has been bothering me about it is the daily cron and maint script and the general plan of migrating to the data gateway while directly using it inside mediawiki.

Let me explain it further. What we currently have is links recommendation system that seems to be decoupled from mediawiki's database and looks nice and all ("modern") but actually, it depends on the core's database. We have a cron that daily updates those values from the service and put it in mediawiki's database which basically defies the whole point of having them in the first place and have been causing a lot of maintenance headache for DBAs doing maintenance of mediawiki databases: T299021: Reduce running time of refreshLinkRecommendations.php to a maximum of 60 minutes (including prolonging several schema changes because the first run failed, etc.)

FWIW, we consulted with SRE + DBA teams when planning the Add Link project (see Add_Link#Updates) when figuring out the architecture. Moving the caching layer into the Link Recommendation service (as opposed to MW tables) is perfectly fine, but a separate discussion. If you'd like for us to consider that, let's make a task for it.

There is no issues with storage capacity of that data, the update pattern seems to be problematic here. I don't mind whether we fix the current setup or completely throw it away in favor of memcached. Whatever works for you.

I was told that these Frankenstein system is temporary but it has been temporary for way too long and I don't think it's wise to add even more cases to it. We should either decide and get it delivered before adding more or design it without keeping data gateway in mind.

This sounds like a separate concern, although there are some similarities in the setup proposed. The main difference is that if we use the data gateway, we will use that exclusively for storage and not make any writes to MediaWiki database tables.

Yes. My thinking is that we don't end up in the same situation again. As long as you think we won't. I'm happy with it.

Just a quick update that I will update this task (or new tasks) as well as the architecture doc sometime tomorrow.

In T309747#8088204, @kostajh wrote:

Just a quick update that I will update this task (or new tasks) as well as the architecture doc sometime tomorrow.

Tasks created:

• T313395: User impact API: Create maintenance script for refreshing data
• T313393: User impact API: Create GrowthExperimentsUserImpactManager, GrowthExperimentsUserImpactLookup, and GrowthExperimentsUserImpactCompute services
• T313330: User impact API: Create public facing API