With Giving Days becoming increasingly popular, the number of technology platforms that host them has also increased.  In this article, Aaron Godert, GiveGab’s Co-founder and Chief Operations Officer, elaborates on the importance of the technology behind giving day platforms.

I’m the COO, Co-founder, and head of technology at GiveGab.I’ve been involved with the architecting and development of our platform starting more than 5 years ago.

I am proud to say building a modern, robust, and reliable system has been one of our biggest priorities over the years.  Not only have we achieved this with our core platform at GiveGab.com, but it has been of utmost importance in building out our vigorous “Giving Day” platform.

Giving Days see a high volume of traffic with up and down spikes in activity all day long.  They can be unpredictable, but one thing is for sure, they generate a lot of buzz and the platform handling them must be rock solid.  

Not only must a giving day platform be a beautiful experience for the donor, that experience must be fast and reliable.

Luckily, the present-day technology world we live in is amazing and has evolved quite rapidly over the past several years.  The advent of Cloud Computing from providers such as Amazon Web Services and Heroku has made the rapid adoption of quality, full stack technologies not only accessible to everyone but also much more affordable.  

Our amazing product and engineering teams have taken full advantage of these modern platforms to produce a market-best experience that I’m proud to say has seen 100% uptime with no performance degradation for all of the Giving Days we’ve hosted.

These are the key tenets we always keep at the forefront of our minds as we evolve our Giving Day platform and the questions you should be asking your Giving Day technology vendor before launching your day:

1. Is it secure?
2. Is it reliable?
3. Is it fast?
4. Is the donor’s experience delightful?

1. Is it Secure?

While this is the most sensitive aspect of running a day of giving, I feel it is the easiest to achieve given the modern Cloud-based services that are available these days.  Not only do they employ top security practices, but they do so in a way that is cost-effective for vendors.

HTTPS/SSL

All user interactions and all data being transferred over the internet must be secure.  This is easy to achieve by putting all interactions with the Giving Day site behind HTTPS (SSL).  This ensures all transport of bits and bytes over the internet are encrypted and private.

At GiveGab: All of our data is backed behind HTTPS/SSL internet connections.  It’s simple, we don’t take chances on this.

Credit Card Data

Not only is it critical that all credit card and payment processing data leverage HTTPS/SSL as noted above, it is important that the data be stored securely by a PCI compliant service.  Luckily, every modern payment provider must do this or they’d be out of business.  

I’m a strong believer that a Giving Day vendor should not be doing this themselves, but instead, should be leveraging one of the many modern, well proven and respected providers.  If they are doing this themselves, they are trying to cut corners and cut down on internal costs.  This adds significant risks to your organization and just isn’t worth it.

At GiveGab: We leverage a market-leading payment provider that does 10s of Billions of dollars in volume each year.  They are PCI Level I compliant – the highest level of compliance.  In fact, your Credit Card data never touches our servers, it goes straight through to our provider and we only interact and charge your card through a one-time use secure “token” that only GiveGab and our payment provider knows about at that moment in time.  This is only good for 20 minutes of activity by you.

Password Storage

If you are collecting passwords, those should be properly stored in a database as a secure hash. Luckily, most Giving Days do not require donors to create an account; therefore, no password should be required.

At GiveGab: We don’t require donors who give on a Giving Day to set up an account.  If they choose, we ensure that the password they choose is securely hashed.

General Data Storage

If you have any sensitive data such as SSN or data that falls under compliance laws, that data should be encrypted using the strongest form of encryption.  Right now the AES (Advanced Encryption Standard) protocol is your best bet.

At GiveGab: We leverage a hosted database service that is a market leader in security.  All of our data is AES encrypted at rest, regardless of whether we consider it sensitive or not.  We simply just encrypt all of it for extra security.

2. Is it Reliable?

One of the worst things that can happen during a Giving Day is having the site become unavailable or certain portions of the system not working at all.  If your donors can’t get to the Giving Day site to find where to give or even worse, aren’t able to donate to an organization, there are catastrophic repercussions, including loss of credibility and donation dollars.

It’s crucial that any Giving Day system is properly architected to be fault-tolerant and redundant.

This means that if certain components of the system fail, it can automatically recover to run on backup services and without disruption. Here are a few of the questions we ask ourselves on a frequent basis about our system architecture as we continue to evolve it:

1. How can it crash?
2. Where are our single points of failure?
3. How can we increase processing capacity as volume increases to avoid a “traffic jam”?
4. How is our data backed up?  
5. What happens if each of our cloud providers has an issue?  
6. How are our providers ensuring reliability?   

That’s a lot of questions, so here’s a framework to think about this with:

Fault-Tolerant Capabilities

If any component fails within your architecture, you should be able to fall back to a backup component.  

Imagine this: You’re grabbing a cappuccino at your local cafe.  You walk in, and two people in front of you order a latte.  The first person gets theirs no problem, but then, as the barista is pulling the shot for the second person, the espresso machine stops working.  At that point, you have already paid and you want your caffeine… unfortunately, the boutique shop only has a single machine and you settle for a refund and a plain coffee.  

If you went to the cafe across the street, this wouldn’t be an issue because they have two espresso machines that they’re using all the time.  Not only are they faster, but if one of the machines goes down, you can still get your cappuccino without complete disruption.  And the likelihood that both espresso machines are broken at the same time is very minimal.  

To bring it back, the best systems don’t just have backups in waiting, they distribute computing activity to replicants (copies) of the components constantly as part of how the systems run, so that if one of the components goes down, the other three are waiting to handle requests and the end user experience does not know the difference.

An example of a component failure could be the underlying server hardware that a database or web server is running on.  If that hardware starts experiencing issues, it should not be a single point of failure.  If you are employing a “load balancer”, this piece of the architecture should be constantly distributing “work” to different “copies” in parallel at the same time.  The risk is small that all “copies” have issues at the same time.

At GiveGab: All of our system components (web servers, content servers, API, databases, etc) are fault-tolerant.  We run on top of the #1 Cloud IaaS (Infrastructure as a Service) provider, Amazon Web Services and our PaaS (Platform as a Service) provider Heroku is a market leader as well.  We always run in a load-balanced environment and as servers encounter errors, the underlying architecture detects this automatically, removes them and adds new healthy ones without disruption to our end user.  Our database is high-available, meaning it’s required to have 100% availability with hot-failover capabilities.  Every layer of our architecture leverages “load-balancing” with replication and geographic distribution. We also leverage failover DNS to battle against DDoS (denial of service attacks).

Redundancy

Redundancy is all about making sure you have backups of data and services in waiting in case something bad happens to pieces of your system and they can’t be automatically recovered through your “Fault-Tolerant” architecture.

For example, let’s pretend a data center is subject to a natural disaster and all the servers are underwater and fried… this has happened before.  Or another example is that the physical internet line (e.g. fiber) is cut and they don’t have a secondary line going into the datacenter.

You should have real-time copies of your data and services in a different unaffected datacenter and be able to stand up that Giving Day site quickly again. Luckily, most modern Cloud providers have this as an option built into their services and it is cost effective to pay for these services to avoid catastrophic failure.

At GiveGab: We leverage HA (high-availability) for our database, which as auto-failover and auto-backups in place to geographically distributed datacenters.  We also run real-time hot-replicants beyond the built-in HA.  We have hourly, daily, and weekly and monthly backups of our data.  Our code is deployable external to the servers it runs on meaning if all servers go down, we can push it out to another server from a central location we control.  We have backups of this code as well.

Ability to React / Recover

It’s important that a technology team can detect and react to Giving Day issues with minimum disruption to donors. 

That requires comprehensive monitoring tools and streamlined development, quality assurance, and deployment procedures.

At GiveGab: We rotate our engineers through different technology roles so that everyone has comprehensive knowledge of each piece of our technology stack.  Our development team follows an iterative process called “agile” which allows us to push out changes at any point in time without downtime or disruption to donors.  We often push out enhancements to our platform daily.  The mechanical aspects of this process are automated through tools with continuous testing built-in to detect errors that could break the functionality of the system before a bad change could make it into production.  We can easily rollback from any change and we have a full audit trail on changes.

We are on call 24/ 7 and monitor our systems from services around the world.  We are alerted if there are errors and often times can detect and fix issues before donors even notice them.

We have full control and access to our technology because we have built if from the ground up. A technology vendor running Giving Days should own their technology and not outsource stack ownership to a partner that is not focused on Giving Days.

3. Is it Fast?

Donors expect to interact with a lightning-fast Giving Day site.  Response times should be measured in milliseconds. Every second delay results in lost donation dollars and leads to a bad donor experience with less repeat giving.  

It’s crucial that the Giving Day site is optimized for high-volume traffic and can add computing capacity as volume increases automatically.

Scalability

This essentially means that the Giving Day site can easily handle high volumes of traffic and avoid crashes.  The best systems scale “elastically”, meaning as volume increases, the system detects this and adds more capacity automatically without engineers needing to get involved.  When the volume decreases, capacity should be removed.  

Auto-scaling is the most efficient use of dollars because it spends no more than what’s needed.  Most modern Giving Day sites offer cost-effective solutions for elastic scalability.  It’s easy to test this through numerous load testing suites.

At GiveGab: All of our services are elastically scalable.  As the load on the system increases, we auto-detect this and add capacity without disruption to the donor.  If load decreases, we remove capacity.  We frequently load test our services.  One minimally-sized server can handle 250 requests/second and this scales linearly.  Our elastic load-balancing architecture detects bottlenecks on throughput and adds servers automatically without human intervention, thus allowing us to process (250 x N servers) requests/second.

An analogy of this is the George Washington bridge in NYC.  During morning rush hour, that fancy vehicle moves the dividers so that more lanes are open for inbound traffic.  After rush hour, it goes back to even lanes.  In the evening rush, it does the same but in the opposite direction.  Pretend there wasn’t a person driving that vehicle and the increased flow was detected automatically and the dividers moved automatically as the traffic ebbed and flowed.  That would be elastic scaling.

Smart Content Distribution and Caching

Much of the content that any Giving Day site needs to present to a donor is static – images, copy, etc.  75% of the content doesn’t change and if it does, it’s not very often.  There are CDNs (content delivery networks) that will help to cache highly requested images, text, and other content as well as make it available in multiple geographic locations for reduced latency (less “distance” between the donor and the content).  

Beyond that, there is dynamic content that does change that can also be cached and periodically refreshed for near real-time information.  Things like overall stats, leaderboards, totals, etc., can provide a user a great experience even if it’s 1 minute old at most.

At GiveGab: We leverage several high-performance CDNs to geographically distribute static and even dynamic content without sacrificing the end user experience.  Our content is available all over the world and served up by servers closest to the donor for reduced latency and maximum speed.  We have several layers of fault-tolerant, fully redundant, highly cached and load balanced content.  Often our backend web servers don’t need to scale up even at high volume traffic because the robust caching scheme and service we leverage.

Smart Application Design

A Giving Day platform needs to leverage modern day software patterns and architecture.  A REST-ful services approach, with independently scalable APIs, is crucial to building a proper distributed system that can leverage Cloud providers to the fullest extent.

At GiveGab: We have architected our application so that all pieces of the software are independently scalable.  This includes a RESTful API that scales on demand separate from our web servers, database, and caching layers.  Dynamic aspects of our platform leverage asynchronous JavaScript techniques to load the page in pieces.

4. Is the Donor’s Experience Delightful?

Donors expect a great Giving Day experience.  It needs to be simple, beautiful, fun, and if they have issues, they need quick access to help.  Without these 4 basic needs being met, a Giving Day is not maximizing its effectiveness and is losing out on donations.  

Donors need to be able to find giving opportunities and donate quickly.  

It should look great anywhere and on any device and should be “mobile responsive.”  They should want to give multiple times to different organizations.

If the donor does need help, they should have access to a responsive support team that they can interact with live versus back and forth over email over long stretches of time.  They should be told when to expect a response.

At GiveGab: We have put painstaking effort into ensuring our user experience is seamless on all fronts and leaves the donor feeling like they have gone through a delightful process.  If your donors really like the experience, they’ll want to give more.

We have a great design and product team that obsesses over simplifying the donor experience and increasing conversions. Our customer success team fields questions in real-time over live chat, all in-house sitting next to the rest of our team for maximum effectiveness.  We respond typically in 2 minutes.  

Most Giving Days see few questions from donors, which reflects our seamless user experience.

To learn more about our Giving Day platform, including testimonials from some of our partners, visit Days of Giving on GiveGab.

About Aaron:

Aaron Godert is the COO, VP of Technology, and Co-Founder at GiveGab.  Aaron has over 18 years of experience as a technology leader in the entrepreneurship, banking, higher education, consulting, and nonprofit industries.  Aaron’s background is in architecting, developing, and integrating large-scale distributed software systems.  He has contributed to large-scale open source software development projects.

Aaron has a Masters of Engineering in Computer Science from Cornell University, an MBA from Cornell University, and a Bachelors of Science from Canisius College.