Fundraise Up transaction performance

Key figures

The platform is capable of processing up to 200 transactions per second in real-time. That allows for 12,000 transactions per minute or 720,000 transactions per hour in real-time.

If there is a need to execute the 201st transaction within a second, 200 of them are executed in real-time, and 1 transaction is scheduled for execution and placed in a queue. The queue is processed in the next second or as soon as the load decreases.

Such an approach makes the platform's performance virtually unlimited. Throughout our history, we have not rejected a single donation due to server overload.

How we handle loads

Web traffic

Before a site visitor makes a donation, they must visit a Campaign Page or the organization's site and see the Checkout. We work hard to ensure our Elements, Campaign Pages, or Checkout are displayed as quickly as possible regardless of the number of visitors.

For this, we use a multi-level caching system and rely on Cloudflare's distributed data center network. Cloudflare has 53 data centers in the USA alone, and over 200 worldwide. Copies of files required for our products to work quickly are stored in each of these. Whenever you change your account settings, we delete cached files in all 200 data centers and replace them with new ones.

As a result, a million donors from New York will see our products at the same speed as a million donors from Sydney.

Backend

Our servers and databases are located in clusters in data centers in several countries. Besides increasing reliability, this helps us balance traffic. Thus, if one of the data centers receives too many requests, some of them are redirected to another.

We also have strict rate limits for accessing our equipment at several levels. This allows us to protect against attempts to direct a distributed attack (DDoS) on our services.

Vendors

We use services from various vendors, which we can access in real-time. For instance, currency exchange rate services (Open Exchange Rates or currencylayer), postal address validation services (Google Places, Lob, or Loqate), email address validation services (Bird or Zerobounce), and others.

Even though all our vendors are industry leaders, and we have no doubts about their reliability, we still put mechanisms in place in the event they should fail.

Even if, theoretically, all these services break down under load at the peak minute, we will still accept the donation. Validations that needed to be done in real-time will have to be postponed and will be completed later when the service returns to normal operation.

Payment gateways

We accept payments using two main providers - Stripe and PayPal.

Stripe has a standard limit of 100 write requests per second per account. On average, two requests are required for one payment, i.e., the standard limit allows for 50 payments per second. In our experience, this is more than enough in 99.9% of cases even during large campaigns or Giving Tuesday.

If you are sure that the load will exceed this value, contact Stripe support. They raise the limit to 200 requests per second simply upon request. Also, we have experience when Stripe raised the limit to 500 requests per second.

PayPal does not have a limit on the number of transactions. Mainly, this is because most transactions within PayPal occur between internal accounts, and also because their work with card payments is asynchronous. If the system is busy right now, the debit will occur in few seconds. You don't need to worry about PayPal's performance.

Controlled slowdown

If you experience a significant spike in the number of donations (from 1,000 per minute), we automatically change the operation of your account. Specifically:

• Data in the Dashboard is no longer displayed in real-time. The delay can be up to 1 minute.
• We stop recording donation data in your CRM in real-time, as usual. Instead, we accumulate changes in large batches and send them to your CRM with a delay of up to 1 hour. This allows slower consumption of the limit on accessing your CRM API.
• Charges for recurring plans (2+ installment) are performed with a delay of up to 1 hour. This helps not to expend the limits of accessing the Stripe and PayPal API.

How we test readiness for loads

Despite all the measures we take to handle large loads, in reality, our systems are loaded only a few percent of what we prepare for.

The real world

To give you an idea of the real use of the system, as of May 2024, we have several clients who did 400K donations per month. In peak minutes across the whole system, up to 1,000 donations occur.

Regular testing

To be confident at any time that the system can handle a load of 200 transactions per second in real-time and the rest of the transactions go into the queue, we have set up a monthly testing process.

At the beginning of each month, our Billing team spends a couple of days deploying an environment identical to the production environment and running several tests that try to drown the system in donations over an extended period.

After each test day, we compile a protocol with the results and a list of steps that need to be taken to prevent the system from degrading in the future.