In Spring 2022, a mid-size Biopharma company asked us to design a few microservices with a Data Store schema and an API.

They expected a first beta release with 2 people in 4 weeks. The API had to be super fast, resilient and elastic.

The lead engineer planned to use a commercial database and Spring Boot.

He is a nice guy, open minded and pretty smart. He listened when we started questioning his technological stack and finally was willing to try something new.

So we proposed to use Domain-Driven Design (DDD) to design the Data Model and Kalix for the API and the High-Performance Backend.

Kalix is new, but behind it's Akka, K8s, etc. Lightbend is developing and supporting Kalix, so it comes with more than a decade of expertise in High-Performance distributed systems.

Kalix is Akka as PaaS. It brings developers all the features of Akka (cluster, sharding, location transparency, event-sourcing, etc.) without having to install and configure almost anything. It enables to focus on business modeling and coding.

Knowing Akka quite well, it did not feel too risky to start working with Kalix.
So, we defined two domain entities, to keep the first iteration rather simple. We wrote the Protobuf messaging code, the corresponding Scala code was generated by the Kalix SBT plugin and we had to write the code for the business logic.

From the entity point of view, everything is automatic. We didn’t need to care about the database, and storing or retrieving objects. Entity objects are just available if the code knows their unique ids. They are living somewhere as “sharded Actors”, ready to process messages. If they are not used for a period of time, they eventually get automatically passivated.

Our testing showed very low latency and very high scalability. The platform seems ideal for real-time Cloud-Native applications.

Relationships between entities (in traditional database design, I would call it Foreign key relationships, belongsTo, hasMany in Rails or Grails) need a bit of thinking: should entities be in the same service package ? Or separated ?

It depends a lot on the DDD model and on the structure of the aggregate roots and boundaries. We ended up implementing the relationships using the Action pattern in a Controller class.

Kalix implements Command Query Responsibility Segregation (CQRS), thus, modifications are totally separated from queries. Those are built as views, similar to Database SQL views.

We are big fans of Evolutionary Database Design and it's supported by the Protobuff layer.

Kalix is a pretty cool technology. It enables building stateful cloud applications that are resilient and deliver ultra low-latency.

If you care about deployment issues and would rather focus on your business architecture and design, and if you want your developers think cloud-first, we recommand giving Kalix a try! It could save you months of work.