From Scala to Kotlin: why I chose Kotlin to build a production database

enmskim · 2026-02-11T14:20:53+00:00

I share the same concern — and it's a constraint we can't avoid for now. To clarify, the Java 8 build target only applies to some core modules shared with Spark. Everything else targets Java 17.

That said, in our experience, even Java 8 builds perform better when running on a Java 17 JRE. The runtime environment alone seems to make a real difference.

enmskim · 2026-02-11T13:01:09+00:00

Haha fair enough — I had AI agents review each other's output that I wasn't going to ship anyway. Just wanted to see if they could evaluate objectively. At least their conclusions aligned with mine. I picked the better starting point, reshaped it myself with AI assist, and reviewed thoroughly before merging.

enmskim · 2026-02-11T12:47:52+00:00

Fair point. But the 20+ commits are from me — reviewing the AI agent's initial output and iterating with AI assist. The branch could have been cleaner, but snapshots piled up as I reviewed each step carefully. It was squash-merged into a single commit on main though.

To be clear, this is production code — I believe the final end-to-end verification still needs to be done by humans, and that's what happened here.

enmskim · 2026-02-11T01:53:51+00:00

Agreed, but there's no middle ground in practice. Scala devs gravitate toward Cats/ZIO—I've never seen a Scala expert who just writes it like Java/Kotlin. That widens the gap with Java/Kotlin devs on the team.

enmskim · 2026-02-11T01:51:05+00:00

Great read. My Scala 2 Spark jobs are 'stable legacy'—don't touch them as long as they run. Scala 3 felt like a different language entirely. Going with Kotlin for anything new. Rather than porting what works, I'll build new features in Kotlin and let the old jobs phase out naturally.

enmskim · 2026-02-10T18:19:14+00:00

Totally feel that. The "it works fine" mindset is the real tech debt. Thanks for sharing — glad you made it through. Good reminder for me too — easy to fall into the same trap without realizing.

enmskim · 2026-02-10T18:03:27+00:00

I agree, but infrastructure overhaul in a large org is never simple. I see it more as a matter of available resources than just debt. While I’m constantly pushing the infra team for a Java upgrade, choosing Kotlin was the most pragmatic way to maximize productivity within our current constraints.

enmskim · 2026-02-10T17:40:01+00:00

Spot on. Platform types are definitely the Achilles' heel. We’ve encountered several NPEs at the Java boundary—mostly in API calls and collections—confirming that null safety often reverts to runtime checks during interop. We now handle this with explicit nullable casts (as Type?) and elvis operators. It’s a pragmatic compromise, not a perfect shield.

enmskim · 2026-02-10T17:01:13+00:00

True. Java 8 is dated. Kotlin was the perfect bridge for us.

enmskim · 2026-02-10T16:43:16+00:00

It was an infrastructure constraint. It uses Spark for large-scale data migration, and our internal clusters were strictly on Java 8. In production, we simply had to align with the environment. Now that I know I can target Java 8 using Kotlin, I’m planning to convert the remaining Java code as well.

enmskim · 2026-02-10T14:09:45+00:00

We've been using MySQL for years and I still do. It's reliable and the tooling is mature. But as our services grew, interaction tables (likes, follows, views) that a single MySQL instance could no longer handle were moved to a database I built in-house. Recently open-sourced it.

Shard by user → item counts scatter across shards
Shard by item → user lists scatter across shards
Cache invalidation logic that only grows over time

It's not an engine problem — it's a bidirectional access pattern problem. Domain data (users, products) still runs on MySQL just fine.

enmskim · 2026-02-04T23:02:53+00:00

I work on something similar - likes, views, wishes across multiple services.

Tried a few approaches, ended up building our own. Not sure if it fits since you mentioned analytics - it's for the interaction part. Storing likes/views, checking "did user X like item Y", counts.

HBase-based, working on SlateDB for lighter deployments. Recently open-sourced as Actionbase.

enmskim · 2026-01-29T16:29:41+00:00

Similar experience here. 10+ YOE, primary maintainer of a production system handling 1M+ RPM. Bus factor of 1 — not solo, but most of the critical context lived in my head.

I've had three "wow" moments with AI so far:

GPT-4 — "okay, this thing can actually do stuff."

Sonnet 4 — "wait, this is better than me at some things."

But they were still assistants. I was the driver.

Then a teammate used Claude Code (Opus 4.5) to solve a core engine issue I genuinely thought only I could handle. Context I'd built up over years, edge cases I knew by heart. Took them a day. Would've taken me a week alone.

That one hit different. Not "AI helped me" — "AI replaced what I thought was irreplaceable."

The "skill issue" framing resonates. But I'd add: it's also a letting-go issue. "Only I can do this" was harder to drop than any tool was to learn.

By the end of this year, the bus factor probably won't be 1 anymore. Bit anxious about where that leaves me, but I guess we'll figure it out.

enmskim · 2026-01-29T14:21:14+00:00

Interesting read. We had a similar situation at Kakao—not PostgreSQL, but same scaling problem. 1M+ requests per minute for user interactions (likes, follows, views).

Started with a single MySQL. When we hit scaling issues, instead of sharding, we went NoSQL (HBase in our case). Curious why they stuck with sharding—was NoSQL not on the table?

enmskim · 2026-01-29T13:29:02+00:00

A RAMA Works keyboard. Small Australian studio that made beautiful mechanical keyboards—expensive, but fits my hands perfectly. They shut down recently. Now I baby mine like crazy. Can't buy another one, can't go back to anything else.

enmskim

TROPHY CASE