[portland] Creating an API with Metered Billing

[Lennon Day-Reynolds]

I've worked on these kinds of APIs before. Jeff's point about counts
lagging # of calls is valid, and totally an architectural and business
decision you need to think about before you sit down to build a
rate-limiting system.

Think of accuracy vs. efficiency here as a slider you can move in
either direction. What's your biggest risk or downside? Would
permitting over-usage for a few of your users harm your service or the
business in some way? (E.g., a voting system should allow zero
over-counting, but a weather API can probably permit a few "free"
over-quota reads.) What's your expected nominal usage rate? Do you
expect big bursts of activity?

If you go the most strict route (e.g., update a counter in your main
app DB for every API request) you'll get very accurate gating, but
depending on your database access and application usage patterns you
could easily end up doing more work maintaining counts than you do
actually providing your service to customers. Worst-case, if the DB
gets swamped then usage counting could actually cause downtime for the
rest of your system.

Log-based rollups are slower to converge, but potentially much cheaper
to maintain (esp. if you have any existing async job infrastructure in
place). Depending on your access rates and how "bursty" traffic can be
they might be a totally acceptable option. You also didn't mention
your underlying web stack, but assuming you're going to run on
multiple hosts you might have to work a bit to gather + order logs in
one place to get accurate rollups.

There's also a middle ground where you use memcached or redis to store
your counts. In-place increments in those systems will be cheaper than
a transactional DB write, though you can't do a simple filter on event
timestamp as you can in SQL. I've commonly used a simple bucketed
storage model with TTLs on each bucket to store a sliding window of
recent access counts.

I haven' vetted any of these implementations in production, but
several people have written libraries accomplishing exactly this
pattern:

http://flask.pocoo.org/snippets/70/
https://github.com/DomainTools/rate-limit
http://limits.readthedocs.org/en/stable/ <- (this one appears to have
both Flask and Django adapters available, too)
https://pypi.python.org/pypi/rratelimit/0.0.4

(& etc., etc.)

On Wed, Sep 16, 2015 at 4:56 PM, Jeff Schwaber <freyley at gmail.com> wrote:
> That's super interesting!
>
> I haven't done usage limits, but I've played with the throttling stuff of
> Django Rest Framework:
> http://www.django-rest-framework.org/api-guide/throttling/ and you could
> definitely put usage counting in there. Once you've got usage counting,
> limits seem like a simple step inside that framework.
>
> The big challenge is going to be that, naively, now all of your API
> requests are database updates, and from a scalability point of view, that
> sucks. Of course you could make them logging statements instead and then
> have a background process reading the log to generate the current counts,
> but then you'll be behind a bit, so users may bounce over the limits a bit.
>
> Jeff
>
> On Wed, Sep 16, 2015 at 4:44 PM, Jason Champion <jchampion at zetacentauri.com>
> wrote:
>
>> Question:
>>
>> Does anyone have any experience with creating APIs that have usage limits
>> and metered billing? Can you suggest any good articles/howtos/resources on
>> the subject?
>>
>> I've created plenty of APIs (REST, XMLRPC, etc.), but they've always been
>> open to all with no auth or billing.
>>
>> Thank you,
>> Jason
>> _______________________________________________
>> Portland mailing list
>> Portland at python.org
>> https://mail.python.org/mailman/listinfo/portland
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.python.org/pipermail/portland/attachments/20150916/d54c2d38/attachment.html>
> _______________________________________________
> Portland mailing list
> Portland at python.org
> https://mail.python.org/mailman/listinfo/portland



-- 
Lennon Day-Reynolds <rcoder at gmail.com>
http://rcoder.net/