From Java to Kotlin: Migrating Microservices at Grindr

In 2021, Grindr, the largest social networking app for the LGBTQ community, pivoted an ongoing Java monolith refactor, and began writing microservices in Kotlin. We consider our work to be a Kotlin microservice success story! In this post, we’ll cover our reasons for moving to Kotlin and the impact that has had on our app’s performance and on our team’s development time. We’ll also talk about some tools and libraries that are integral to our architecture, including the framework and testing library that we use.

In the beginning…

This story actually begins in 2020 during the height of the pandemic. Grindr saw an unprecedented increase in DAU (daily active users). As you can imagine, people needed a way to connect and dating apps played a huge role in this. At that time, our backend system was primarily a Java monolith service, or more precisely a Java “distributed monolith” system. We had begun breaking the original monolith apart into domain centered services. These were not true microservices- they connected to multiple databases and contained way too much functionality. And with the increasing traffic, the system was not handling it well.

Java Stack and Architectural Pain Points

It’s often easier to understand the limitations of a system once you’ve moved beyond them. I think that is definitely true in this case. These may sound very familiar- they are definitely not unique to the Grindr architecture. Java 8 “Enterprise” design patterns are quite verbose. In our codebase we have plenty of pointless interfaces and their implementations. This can make it difficult or at least daunting to new developers, regardless of their Java experience. There is a lot of boilerplate code that goes into writing Java and frankly, it’s a whole lot of typing. Java’s lack of null pointer management is something that we’ve all fallen victim to, I’m sure.

Language aside, we had many architectural issues that added to the complexity and fragility of the system. Circular dependencies were quite easily introduced. A centralized service for configurations across the system was hard to manage and became even harder with the introduction of microservices. Our codebase was littered with internal wrappers for libraries that weren’t needed. We struggled with keeping dependencies up to date (especially with Java and Dropwizard). Test mocks (testing the mocks) were the bane of many developers’ existence. We often spent more time changing our tests than we had spent changing the logic that broke the tests.

Migration Timeline

As you can see from the timeline above, we introduced our first Kotlin services in 2021, but we didn’t finalize our tech stack until later in the year. Although the move to Kotlin itself was fast, the use of Spring and Spring Boot still had too much overhead on development time and we were still seeing some performance costs. We could do better.

Project Decaf is the official name of the project to move all of our backend code from Java to Kotlin (get it?! decaf(feinated)). We managed this project fairly simply with Confluence and Jira. The project’s success is due mainly to the dedication of our engineering leadership to prioritize this tech debt. Our goal is to be a 100% Kotlin shop by the end of 2023 (this year!).

Why Kotlin?

Sometimes it’s just good to code what you know! A few of our engineers at the time had previous experience with Kotlin. In early 2021, two new micro services were introduced with Kotlin as the language, Spring as the framework and Spring Boot as the service. Kotlin is a statically typed, functional programming language developed by the JetBrains team. It compiles to run on the JVM (and JS VM). The guiding principles of Kotlin are what make it such an effortless language to work in- conciseness, safety, pragmatism and interoperability. While the details of these principles are outside the scope of this post, they are worth keeping in mind as you start (or continue) your own Kotlin journey.

A deep dive into the Kotlin language is also outside the scope of the post, but It is worth mentioning some of our team’s favorite Kotlin language features!

• Kotlin provides top level functions as well as classes (you don’t have to put everything inside a class)
• There are so many great Kotlin standard library extensions to the Java standard library
• Kotlin data class “freebies”
• String templates
• Extension Functions
• Kotlin’s concise constructors negate the need for dependency injection

Our new Kotlin stack and its impacts

As mentioned previously, our v1 Kotlin services were using Spring/Spring Boot. With this infrastructure, we were still experiencing slow start up times for services, which often had a ripple effect across the system. By the fall of 2021, we were experiencing some significant outages and spending a lot of time trying to bandage the system. This is when a framework and set of tools were introduced which we regard today as our standard service stack. This stack is based on the a template created by our Chief Architect and VP of Engineering, Sam Samuel (affectionately known as SamSam). It can be found on github and consists of the following:

• Ktor HTTP Framework
• Kotest with Testcontainers (Testing)
• Hoplite (Configuration)
• PostgreSQL
• Kafka (Event bus)
• Flyway (Database migrations)
• Spring JDBC Templates / JOOQ
• Lettuce (Redis client)

We’ve experienced so many improvements with this new stack, but let’s highlight the ones with the largest impact. Less outages! Outages are no longer the rule, but the exception. We are more confident in our ability to iterate quickly without inadvertently causing an issue. We are no longer restarting services just to keep things afloat. It’s much easier to scale Kotlin Coroutines than Java threads and our service pods now use less resources. We’ve seen a definite improvement in call latency between services.

The impact of our new stack is not limited to the stack itself. We’ve also seen a huge decrease in the time it takes new developers to start contributing meaningfully to our codebase. These quotes from engineering team members speak for themselves:

• “Never having to use mockito again has brought so much joy to my life. I no longer hate writing tests.”
• “Dev time has reduced drastically! Coroutines are great, exception handling is heaps better.”
• “New developers can learn a microservice in days, and contribute extremely quickly”
• “We’re now sharing a language with the Android team which can lead to more cross over development.”

Where to start with your own Kotlin migration

Sometimes knowing where to start is the hardest part. There’s not a one size fits all solution, but at Grindr it was much easier to create new kotlin services from scratch with our new stack, rather than trying to retrofit existing services with Kotlin. However, keep in mind that Kotlin does provide 100% Java interoperability, so it’s absolutely possible to start converting parts of an existing service to Kotlin. We just didn’t feel that was the best approach for us. My advice to you is to research various migration approaches, try something out, and iterate on it! You’ll figure out what works best for you. And if you’re brand new to Kotlin, here are some great resources that we’ve found helpful for learning the language:

• Official Kotlin site (kotlinlang.org)
• Koans (https://play.kotlinlang.org/koans/overview)
• Kotlin for Java Developers (https://www.udemy.com/course/kotlin-for-java-developers/)

In conclusion…

A successful microservice migration is often an anomaly by itself, so we are really proud that we were not only able to tackle this enormous challenge, but that we were also able to transition to a preferred language team-wide and a tech stack that solves our most important issues. The biggest factors in our success have been getting buy-in from both the leadership team and engineering team, iterating quickly and often, and clearly defining the steps needed to get where we are now (Project Decaf). I hope this helps you in your own migration journey!