Since summary and mobile-sections-lead endpoints contain wikidata description, we have a rule in ChangeProp that is intended to rerender summary and mobile sections once the description change. However, unfortunately we've had to set up this rule to react to revision-create event, so we're rerendering on ANY wikidata item change, not just description.

It would be great to narrow this down, because this rerendering could create a significant load (~100 req/s) on mobile cluster, and most likely this load is unnecessary. 100 is 2/3 of the overall mobile cluster load, so it's quite critical.

The current idea is to introduce fragments array property into the revision-create event. The semantics would be the IDs of the changed sections/components. So, for wikidata description change the array would contain wb:description string. The change propagation would match on this.

The fragments property is not a one off solution, it can be later reused for way more things. For example, if we included component:lead-section ID only when a lead section is changed, we could significantly lower the summary update rate, and improve the granularity of the mobile updates. Opportunities are endless.