We are now, simply, Redis
‘Twas only a fortnight ago that you were invited to an #NYCSQL Database Month Tech Talk by Grindr‘s Lukas Sliwka, and now the Tech Talk’s video is already online. The room was packed wall to wall and much like it, Lukas’ talk was filled to the brim with insights and knowledge gained from building an app that can scale to match the service’s huge success. The talk focused on two main points: people and speed. Not only is Grindr’s app all about these two concepts but the company’s technology choices are as well!
Whereas a user might be looking for people with the right attributes in the flesh market, Grindr looked for people with the the right skills to build and operate the infrastructure that its app requires. The infrastructural decisions are not only influenced by technical requirements, but also by the availability of the right people, specifically those with experience in the company’s chosen programming languages (PHP -> RoR -> Java & Scala, in Grindr’s case) being one such example. But it’s also all about latencyspeed, so naturally Redis is key here and Grindr knows its Redis intimately — the team used to run an in-house, self-managed Redis cluster with 100+ shards. The challenge, especially in a budding company, is blending the right mix of in-house skills and partner skill sets. The right pairing will allow your company to focus on its competitive edge, while handing off ownership over domains that are your partner’s core experise.
I recommend that you watch (or listen) to the entire session (70:27 minutes) – Lukas is a natural public speaker who knows his tech, has a great story to tell and delivers it with a good measure of humorous anecdotes. The session provides an authentic glimpse into the evolution of a startup-cum-major-success and of the challenges that it grapples with daily. Besides Redis shoptalk, you’ll be able to pick up some good tips and lessons about what it means to build a mobile app that uses a geographically distributed infrastructure to ensure global availability and responsiveness. Naturally, my favorite quote from the talk is below:
“We partnered with Redis for a couple of reasons […] The [Redis] cluster that I described, that served 110,000 queries per second, was awesome but it required a high DevOps footprint. I needed to have engineers constantly tweak things, look at things, if that thing went down it was a disaster. So I don’t want that headache. I want to be able to build stuff that allows guys to meet faster, as opposed to s******g around with Redis and understand all the intricacies how to configure it. So Redis is one of the companies that provide that service and we’ve actually transitioned our Redis infrastructure to them […] because we needed to squeeze that extra performance out of it.” (at: 21m00s / 21m00s)