Looks like the simplest option is to expose the trending articles via a RESTBase endpoint wish some optional time window parameters, like

/feeds/trendnig{/year}{/month}{/day}{/hour}

And store the data in a dedicated bucket? Omitting the date parameters would give the current data, adding them gives the data for specific year/month/day/hour. What do you think?

We've discussed this in a meeting and the consensus was that the mobile apps would need a way to get information about (i) what's is trending now; and/or (ii) what has been trending in the last 24 hours. However, keeping historical data about what pages were trending in a given point in time seems also useful. IMHO, we should defer that for another iteration.

So, yes, we definitely need a bucket in RB for this. The question is how to keep it up to date. One solution could be to expose the whole list with its metadata (number of edits, names of editors, edit bias, etc) via an endpoint, similar to @Pchelolo's suggestion. If the list is complete, the trending service could use that info to update it on each edit and re-POST (or PUT) it. It is not clear at this point how would it discern when to evict a page from it, though, as it depends on when the edits that made it trending were made. We need to come up with a strategy here.

The apps would like to be able to retrieve a list of all things that trended in the past week.

Why as long as a week?

The storage requirements change quite a bit with the time frames. If we are talking about things trending from one week to another, then we'll probably want to keep around historical edit data. If we are primarily interested in short term spikes with time scale on the order of minutes to hours, then we might not need any storage beyond Kafka at all. We could still store / cache the *results* of such a short term trending service, but we wouldn't need a week's or even day's worth of detailed historical data for each article.

Also, are we interested in all relative changes beyond some percentage, or is there also a minimum activity threshold for anything to be considered trending? If there is a threshold, then the state needed would be significantly reduced again.

@mobrovac @GWicke my concern with short term storage is that certain pages like Donald Trump would trend on a regular basis. We can either avoid these duplicate events, by using a window like a week (notifications once a week might be bearable but using days is probably too short) or store everything that ever trended and look at the last 50 trends to remove duplicates.

I think it's up to you to enforce we work within some constraints for the first version and we'll do the best we can, but I guarantee we will need storage on the long term to make this service useful.