Contrasting Kafka with Akka
My software architecture consulting gigs take me places ranging from startups to more established organisations, having one thing in common: they are looking to solve a problem using a distributed systems approach. Organisations are quick to embrace the benefits of microservices and event-driven architecture—scalability, supporting business change, polyglot culture, deployment flexibility—values that organisations are increasingly looking to adopt.
These architectural paradigms aren’t without their drawbacks too, however. Distributed systems are trickier to debug. Consistency and distributed state don’t play well. Concurrency is a lot more difficult to muster. To the latter, the use of actor systems and related forms of command serialization is becoming more prominent in a contemporary architecture landscape.
Perhaps unsurprisingly then, I often get inundated with questions about Kafka and Akka—how the two relate and whether we should be using one over another—almost as if to say they were in some way interchangeable. I felt it’s time to dispel some misconceptions and objectively delineate their commonalities and differences.