What are some authorization based design patterns to limit functionality from the perspective of size or amount of data?

Question

I am well aware of role based / activity based authorization in the context of limiting user functionality in a simple on/off manner; however, the problem gets difficult when it's not so black and white.

Take for example:

User A: Is a paid customer of a market data service and has unlimited requests
User B: Is free tier with a maximum of 1000 requests per month

Both users use the same endpoint /api/ticker/AMD?someParam=123

If business rules stated free users could not get market data then it would be as simple as using some declarative style authorization filters to block a call from ever occurring.

[Authorize(Roles = "Paid")]
[HttpGet("ticker/{symb}"]
public IActionResult GetMarketData(string someParam)

It would be fairly easy to implement specific domain logic in the code that needs to be restricted on a case by case basis but that would lead to lots of redundancy.

The only things I can think of right now are:

1. Implementing some type of middleware that is injected in the HttpRequest pipeline and contains a factory that would check which endpoint is being called and thus run specific code to limit requests, or limit data output, or any other business rule.
2. Move to an actor based pattern (such as akka.net) where actors can easily be added within a specific domain flow (but this won't work with simple synchronous GET requests)

I like approach 2; however, as state in parenthesis, this will not work with simple reads. Through my research it seems akka excels at more of a process based workload.

Approach 1 seems a bit cluttered. It also somewhat seems to mix domain knowledge with technical details.

Are there any well known patterns out there for limiting application functionality in a more conditional format rather than just flat out limiting functionality completely based on roles or activities?

Answer 1

This is not an authorization problem; it is an accounting problem.

The subscription is for your company's product. These transactions are sales. This is your core business.

I would do a deep dive with the product owners to uncover potential use cases for:

• Customer onboarding
• Rate limiting (your question)
• Invoicing and auditing
• Customer support
• Refunds or credits
• Fraud detection

Also I would chat specifically with the marketing team on what sort of changes (bulk pricing, regionally-targeted pricing, tiers of service) they envision as they adapt to competitive markets. You don't want to be the stick in the mud who has to say, "we can't support that" down the road.

Once you have the uses cases (they can just be drafts) and some notion of the potential evolution of the product, you will be able to evaluate architectures in support of it. In many cases, the needs of the business require that you actually own this code so that you have complete control over it. This is your business' core competency, after all. In other cases it make more sense to conform to a standard accounting model or one that is used in the industry and compatible with other third party's object models (e.g. for MIS applications). There is no one right answer.

I would not tie this problem to an authorization model as that will tie your hands and affect your company's market agility. It is a business problem.