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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> 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 > [email protected] > https://mail.python.org/mailman/listinfo/portland -- Lennon Day-Reynolds <[email protected]> http://rcoder.net/ _______________________________________________ Portland mailing list [email protected] https://mail.python.org/mailman/listinfo/portland
