A Serverless and Go Journey

Evolution of the Capital One Credit Offers API

Jaime Garcia
Nov 21, 2018 · 7 min read
Image for post
Image for post

As a tech-driven financial company, one of our biggest goals at Capital One is to use technology to easily, quickly, and directly engage with our customers. One important way a potential Capital One customer can engage with us is through our affiliate channel. Affiliate partners like Credit Sesame, CreditCards.com, and Bankrate have a special partnership with Capital One where they display available credit card options and guide potential customers to the credit cards that are right for them. For our affiliate partners, this is done through the Credit Offers API. We like to think that it helps people make smarter credit card choices. We also like to think it shows off our cutting edge use of technology.

What is the Credit Offers API?

When version 1.0 was built in 2015, Credit Offers was built in Java. The current version of the API, version 3.0, has been rebuilt so it is full serverless and written in Go. These are two really cool technologies and combined they’re a fast and powerful way to expose and showcase our credit card products.

Why Go?

At the time, no single team member knew Go, but within a month, everyone was writing in Go and we were building out the endpoints. It was the flexibility, how easy it was to use, and the really cool concept behind Go (how Go handles native concurrency, garbage collection, and of course safety+speed.) that helped engage us during the build. Also, who can beat that cute mascot!

The whole process of rewriting the Credit Offers API in Go was much simpler than expected. In my role as Tech Lead I am the last one to approve when a piece of code will be merged and ready for release. So I had to get deeper into Go to not only understand the code, but the business logic as well. One of the more satisfying surprises was that mixing in business logic with a simple language like Go meant it was very easy to jump into this role and not be a bottleneck for releases.

The next technology we wanted to explore was serverless. By definition, Go is fast and simple, which is also how you would define a lambda. In fact, we didn’t want to go serverless without Go. Which brings us to…

Why Serverless?

We were drawn to serverless because of the combination of its four main pillars:

Image for post
Image for post

Because of the affiliates channel and the way the Credit Offers API impacts our partners and potential customers, it was really important to be able to seamlessly scale our API without interruptions in service. Going serverless has not only allowed us to move away from servers, but it’s allowed us to be faster and more resilient. One of the biggest “wins” has been that our developers do not need to stop and worry about infrastructure and can dedicate more time to creating and delivering business-related features.

Image for post
Image for post

In this pic you can see how simple the architecture is. How we integrate with Amazon CloudWatch to monitor the health of the system. We elected DynamoDB for its escaping capabilities and flexible schema; for long term storage we use a S3 bucket. We also use Amazon’s SNS for alerting when there’s an issue. You can also see how we incorporated an external monitoring system — New Relic.

And again, a lambda sounds simple but we do have some complex processes including calling external APIs that are part of the pre-qualification flow. Go goroutines and lambda are a match made in heaven.

Another key piece of our serverless solution is how we do deployments. Canary deployments allow us to deploy 5% of any lambda update (versioning), set specific canary-deployment alerts, and if something fails, rolls it back automatically without any intervention. After the first 5% release succeeds, we figure out how long we want to test, and start incrementally releasing the new version of the lambda from there. Canary deployments have been really powerful for us. Like I mentioned, we have dependencies with our affiliates, and as we’re scaling and growing our new releases cannot go down. By using a solid pipeline with canary deployments they don’t.

Image for post
Image for post

Lessons From Our Serverless and Go Journey

#1 Serverless doesn’t mean you lose control.

#2 Testing is fundamental.

#3 Mind your data and your databases.

#4 Keep it simple.

#5 Enable distributed tracing.

#6 Design your serverless pipeline with canary deployments in mind.

#7 The microservices mindset.

Results

Image for post
Image for post

We saw some great results in terms of performance gains, cost savings, and team velocity with serverless. A 70% performance gain from the time the lambda gets the request to the time it replies back is pretty impressive. Even more impressive is our big achievement with cost — 90% savings by removing EC2, ELB, and RDS. And as the Tech Lead, the 30% increase in team velocity we gained by not spending time patching, fixing, and taking care of servers is time we can now spend innovating, creating, and expanding on business requirements.

Now that the API is 100% serverless, we have a solid roadmap of what else we want to do with the technology. We want to incorporate AWS CodeBuild to create a simple pipeline for multiple build processes, we want to use AWS Step Functions to add better retry mechanism, and we want to incorporate ELK into our logging so we can add some business dashboards to our solutions. But we’ll save that for another post.

Related:

Image for post
Image for post

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2018 Capital One.

Capital One Tech

The low down on our high tech from the engineering experts…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store