Why I obsess over distributed systems

The question that changed how I think

When I first joined Rakuten, I asked a senior engineer: "Why are we replacing a batch job with Kafka?"

His answer wasn't about Kafka. It was about guarantees.

Batch jobs make implicit promises they can't always keep. Streaming systems force you to be explicit about what you guarantee — at-least-once, exactly-once, ordering. That conversation rewired how I think about software.

Fundamentals age well

Frameworks come and go. The CAP theorem doesn't. Understanding why distributed systems can't simultaneously guarantee consistency, availability, and partition tolerance is more useful than knowing the latest JavaScript framework.

This is why I grind LeetCode — not to memorize solutions, but to sharpen the underlying thinking.

What I'm building toward

I want to be the kind of engineer who can look at a system and immediately understand its failure modes. Not just "this might be slow" but "this will lose data under a network partition unless we add idempotency here."

That's the goal. Everything else is just steps toward it.