Availability and reliability are paramount for all web applications and APIs. If you’re providing an API, chances are you’ve already experienced sudden increases in traffic that affect the quality of your service, potentially even leading to a service outage for all your users.
The first few times this happens, it’s reasonable to just add more capacity to your infrastructure to accommodate user growth. However, when you’re running a production API, not only do you have to make it robust with techniques like idempotency, you also need to build for scale and ensure that one bad actor can’t accidentally or deliberately affect its availability.
Rate limiting can help make your API more reliable in the following scenarios:
- One of your users is responsible for a spike in traffic, and you need to stay up for everyone else.
- One of your users has a misbehaving script which is accidentally sending you a lot of requests. Or, even worse, one of your users is intentionally trying to overwhelm your servers.
- A user is sending you a lot of lower-priority requests, and you want to make sure that it doesn’t affect your high-priority traffic. For example, users sending a high volume of requests for analytics data could affect critical transactions for other users.
- Something in your system has gone wrong internally, and as a result you can’t serve all of your regular traffic and need to drop low-priority requests.
At Stripe, we’ve found that carefully implementing a few rate limiting strategies helps keep the API available for everyone. In this post, we’ll explain in detail which rate limiting strategies we find the most useful, how we prioritize some API requests over others, and how we started using rate limiters safely without affecting our existing users’ workflows.
For our products, like the trivago hotel search, we are using Redis a lot. The use cases vary: Caching, temporary storage of data before moving those into another storage or a typical database for hotel meta data including persistence.
One of the key problems in onboarding developers to use modern Common Lisp is the vertical wall of difficulty. Things that are routinely problematic:
- emacs use. Most people don’t use emacs.
- Library creation. Putting together ASDF libraries and using them is a fairly horrid experience the first time.
- Selection of Lisp implementation to use, along with an up-to-date discussion of pros and cons.
- Putting together serious projects is not commonly discussed.
This site is dedicated to handling these problems. My goal is to put together an introduction/tutorial for practicing professionals and hobbyists from other languages. People who want to get started with Lisp beyond just typing into a REPL. Right now, it feels like this information is less disseminated and much less centralized than it otherwise might be. It’s not intended to be a HOWTO for Common Lisp. That’s been covered quite well. But it is intended to be a HOWTO on how to put together a Lisp environment.
Anyway, I’d like to collaborate with other people to make this a remarkably fine Lisp help site. Contributions are both accepted and welcome. It’s a wholly static site at this point in time – I don’t see a need for articulate-lisp.com to have a dynamic backend. Perhaps/probably one of the code examples will be a webapp.
P.S.: feel free to contact me for anything you like.
Polymer vs. React—which should you use? It’s a question that inevitably crops up whenever anyone discusses the components-based future of the web. While both Polymer and React are libraries created to support a component-oriented approach to front-end web development, they do so in very different ways. In this article, we’ll try to illustrate the role each of these technologies plays in front-end web development so that you can decide which is best suited for your needs.
Around September of 2016 I wrote two articles on using Python for accessing, visualizing, and evaluating trading strategies (see part 1 and part 2). These have been my most popular posts, up until I published my article on learning programming languages (featuring my dad’s story as a programmer), and has been translated into both Russian (which used to be on backtest.ru at a link that now appears to no longer work) and Chinese (here and here). R has excellent packages for analyzing stock data, so I feel there should be a “translation” of the post for using R for stock data analysis.
This post is the first in a two-part series on stock data analysis using R, based on a lecture I gave on the subject for MATH 3900 (Data Science) at the University of Utah. In these posts, I will discuss basics such as obtaining the data from Yahoo! Finance using pandas, visualizing stock data, moving averages, developing a moving-average crossover strategy, backtesting, and benchmarking. The final post will include practice problems. This first post discusses topics up to introducing moving averages.
NOTE: The information in this post is of a general nature containing information and opinions from the author’s perspective. None of the content of this post should be considered financial advice. Furthermore, any code written here is provided without any form of guarantee. Individuals who choose to use it do so at their own risk.
Lisp is a deep language with many unusual and powerful features. The goal of this tutorial is not to teach you many of those powerful features: rather it’s to teach you just enough of Lisp that you can get up and coding quickly if you have a previous background in a procedural language such as C or Java.
Notably this tutorial does not teach macros, CLOS, the condition system, much about packages and symbols, or very much I/O.