You can find a good introduction to AWS re:Invent in my Day One recap.

Welcome reception day. Monday is your appetizer and Tuesday is kinda like that garden salad you get before your entree. At this point most attendees are checked in and ready to hit sessions hard.

The major events for Tuesday are the Global Partner Summit and Welcome Reception. Global Partner Summit is for those special AWS partners. I have never been to one, but I believe there is likely a few announcements for those in attendance.

The Welcome Reception is in three locations this year instead of just the one location last year. It is typically a massive tech expo with about every major tech company in attendance. What is the draw of the reception? One word, swag. Of course you are getting free swag in exchange for something, your work email address. Swag carefully my friends, or link your badge to something you can filter out of your email.

Outside of the major events, there is of course your usual breakout sessions. Here is a breakdown of the sessions I attended today.

Photo by why kei on Unsplash

From Minutes to Milliseconds: How Careem Used Amazon ElastiCache for Redis to Acclereate Their Ride Share Application

This talk was about how Careem leverages ElastiCache to improve their ride hailing match making functionality. Careem faces interesting constraints given they are operating in the Middle East. A few they mentioned that jumped out to me:

Infrastructure is not as matured as our infrastructure in the US.

Different countries have different legal requirements.

Low end cell phone technology, cheap Android devices.

The focus of the session was on how Careem needed to provide low latency matchmaking for both it’s Captains (drivers) and Customers. They needed to decrease the amount of time to matching the two from 2 minutes to 15 seconds. To improve this came down to reducing their ping rate from 1 every 60 seconds to 4 every 60 seconds.

To make that happen they took on two challenges. One was to change their backing storage from MySQL to DynamoDB. This was to decrease the amount of time to read the Captain ping history. The second was to add caching via ElastiCache in front of Dynamo to quickly get the latest ping for a given Captain.

I learned a lot from their approach to using ElastiCache. They created a clustered Redis cache keyed off the Captain id combined with the geo-location hash.

captain:343,geo:aabbcc

These were the keys to a sorted set that contained the history of pings for the given Captain. This was a slick solution and something I was not familiar with at all. Leveraging the sorted set to track the pings and geo locations gave Careem the ability to provide far better ETA for a Captain picking up a Customer.

If you are a bit naive about the Redis implementation of sorted sets, give this a read.

Learn to Build a Cloud-Scale WordPress Site That Can Keep Up with Unpredictable Changes and Capacity Demands

I am not a WordPress person. I don’t run a WordPress site today, but I do receive a lot of questions on Twitter about running WordPress on AWS. So I went to this session to learn more about this world.

I not only got to learn more about this world, but this talk was actually all about using Elastic File System (EFS). It was a double whammy of learning for me.

The interesting bit about this talk was leveraging EFS to share WordPress files across instances. Effectively making WordPress web servers stateless. You trade a bit of latency for more scalability, resiliency, and durability across your WordPress site. This was a nice example of a use case for EFS that is very practical.

There was more bits about using Aurora as a database and ElastiCache for caching database reads to reduce query load. But, the focus of the talk was EFS. Using a shared file system across instances makes it simple to remove state from the web servers.

The downside? Elastic File System throughput is quite confusing. The file system is burstable, meaning you can spend burst credits to get higher throughput.