> Would that be simpler and more effective and preventing abuse?

More effective, no.  Simpler, possibly.  tl;dr - not sure it matters very much, except in how we present this info to the user.

I think that the point of having limits was so that:

1.  A user cannot completely fill up the DB with a gagillion bits of data, which having absolute limits across the product would prevent as effectively as limits per group per policy.
2.  A user can't have a million policies or groups and then list all at once, which will hose our system.   Pagination will probably mitigate this problem?

If it's 1000 groups, 1000 policies per group, 1000 webhooks per policy, the user can still have in total 1e9 webhooks, they just can't hang it all off of a single policy.  So I don't think there's that much difference implementation wise in enforcing the limits.  Checking the current policy count across the tenant no easier than checking the policy count for group.

I think limits per group per policy make more sense conceptually, but presenting it informationally will be tricky.  I think absolute limits across the product are not as nice conceptually, but will be nice and easy to present to the user.

I guess it mainly matters how our users are planning on using their limits - if we have absolute limits, they will be responsible for distributing their allowed policies/webhooks across all their groups.  If we have per X limits, they can be sure that a new group will be guaranteed to get 1000 policies, etc.