Caps should be per type, not one shared budget

What it is

Frequency caps should be counted per type, not against one app-wide total. After chat burns a shared budget, security alerts and pickup codes must still be able to send; after marketing burns it, order updates must not stall. A shared total ties high- and low-consequence items to one meter; whoever arrives first writes the fate of whoever arrives later.

This is how quotas are sliced. It is not "too much volume trips whole-app disable"—that is the disable funnel—and not how timezone and sleep choose an hour.

Why it happens

A total assumes arrivals are interchangeable. Loss functions are not: missing a code is not missing a pitch, and extra idle chat is not extra fraud-control. On a shared meter, high-frequency low-consequence types crowd out low-frequency high-consequence types, and the product then blocks the latter with "already pushed today." Independent caps give each type its own saturation point; crowding is isolated.

Independent is not infinite. Each type still has a cap; overflow stops only that type, and other meters do not move. Security can have a very high cap or none, marketing a very low one—that is the shape of the quota, not another master switch.

Studying it

Give mixed arrivals a "N per day total" versus "n per type." Watch whether high-consequence types are dropped on chat-heavy days, and whether marketing can still fill a shared total under a transactional cap.

Independent variables: shared vs per-type quota, shape of each cap, whether high-consequence may exceed. Dependent variables: high-consequence items dropped by quota, share of a shared budget eaten by marketing, later type-off and master-off.

Uniform lab traffic will not show crowding. Use a real burst (group chat) and then inject a security event. Total arrival count is not compliance—a shared total can be "in budget" while dropping the wrong type.

Where it stops holding

A one-type app's independent cap collapses to a total; do not invent categories for the sake of it. Cross-type digests ("you have 3 things") sent as one item need a predeclared type so the digest cannot dodge a marketing cap. Legally required delivery must not be dropped by any product quota; when a budget is spent, drop deferrable types.

Applying it

• Give each type its own counter; overflow silences or defers only that type.
• Do not share a meter between security/time-critical transactions and marketing/achievements.
• Dashboards should show used/cap per type, not one household number.
• Verify by filling the chat cap, then sending a pickup code and a promotion. The code should arrive; the promotion should hit its own cap or already be low. If the code is missing too, the budget is shared.

Related

• Within the group: H5.10.2 Quiet hours must still let high-urgency items through · H5.10.3 Queue pending items into one send window instead of dripping them · H5.10.4 The cap's reset period must be visible
• Adjacent: H5.07 Push frequency · H5.09 Category subscriptions · H5.01 Urgency grading
• Search terms: per-category cap · frequency budget · quota isolation