Track Repeated Approval Alerts and Safely Update Alert Levels

Extend a work-order approval flow with a cache that tracks repeated alerts and causes rejection when an alert-count rule is met. Then support updates to an alert's level. ### Requirements and Constraints The task supplies the repeated-alert rejection behavior and the alert-level update extension, but not the cache key, count threshold, time window, level definitions, or retroactive effect of a level change. Clarify these rules before implementing a specific policy. Explain a design that keeps cached state, alert updates, and approval decisions consistent. ### Part 1 — Count Alerts and Apply the Rejection Rule Describe the stored data and the operation that records an alert and determines whether a work order should be rejected. #### What This Part Should Cover - The entity being counted, the cache key, and the definition of a qualifying alert occurrence. - The configured threshold and any expiration or time-window rule. - Duplicate delivery, concurrent updates, and the relationship between cached state and authoritative state. ### Part 2 — Update Alert Level Describe how an alert's level can change and how that update affects counts and decisions. #### What This Part Should Cover - Whether level describes an alert instance, an alert category, or the approval policy. - Whether changing the level modifies historical contributions or only future decisions. - Cache invalidation or versioning, safe recomputation where needed, and auditability of earlier decisions. ```hint An update may change membership, not just a label If only some alert levels count toward rejection, changing a level can move an existing alert into or out of the counted set. Decide whether that policy is retroactive before adjusting a counter. ``` ### What a Strong Answer Covers The design makes the missing business rules explicit, preserves the repeated-alert condition and level-update requirement, handles concurrent and repeated events, and explains when a cache is a reconstructable optimization versus the authoritative record. It does not invent a specific rejection threshold or alert taxonomy. ### Follow-up Questions 1. What happens if the same alert is delivered twice? 2. How would you update the count if an alert's level changes from a counted level to an uncounted level under a retroactive policy? 3. Could cache eviction cause a work order to be approved incorrectly, and how would you prevent that?