Introducing Kalix - High-performance microservices and APIs with no operations required. Learn More.
akka-serverless serverless

Developing Serverless Applications - Part 2: Limitations of Stateless Functions


Akka Serverless is now Kalix. Learn more at

There and back again: a tale of two restaurants

In Part 2 of our series Developing Serverless Applications, we look into the limitations of a stateless-only approach to serverless functions. To explain the concept of stateless vs stateful in plain words, we'll use a comparison between two types of restaurants. Bear with us for a moment here :-) 

Imagine that you are planning to dine in a restaurant (aka, the good old days). You have two options: Chez Stateless Lounge, and Le Stateful Boulangerie. Let’s see how they compare...

Chez Stateless Lounge - An Experiment in Frustration

You sit down. The server comes up to you, and asks “What would you like?”. You order a coffee and are about to order more, but the server promptly disappears.

A few minutes later, another server approaches your table and asks “What would you like?”. You inform them that you’ve already ordered a coffee, and they ask you to wait while they go and check your order.

They come back soon and say, “I see you’ve ordered a coffee, did you want something else?” You order a sandwich, and are just about to ask whether you can substitute something but the server has already left to place this order.

A few minutes later, yet another server comes to you and asks “What would you like?” You say that you only wanted to ask about switching the fries for a salad, when they excuse themselves to go check your order. When they return, they say “I see you’ve already ordered a coffee and a sandwich.”

Summoning all the patience you have at your disposal, you calmly explain that you have ordered a coffee, and a sandwich, and that you have another request. At this point, the server smiles and says, “I’m sorry, I can only order new items, not change existing ones.” You get up to leave just as your coffee arrives.

Le Stateful Boulangerie - The Normal Way

You sit down. The server comes up to you, and asks “What would you like?”. You order a coffee, a sandwich with salad instead of fries, and a slice of apple pie.

The server says, “Great, got it. I’ll be right back with your coffee and the rest will be coming out to you shortly.” You eat lunch happily, and vow never to return to Chez Stateless Lounge. The end.

Which Would You Choose?

So let’s be realistic–Chez Stateless Lounge would never stay open more than a week. It’s absolutely ludicrous to imagine a customer order (the entity) in a restaurant being treated in a stateless way. Simply put, this would never happen in real life...

Yet in computing, stateless services do this all the time–every time a request is made, they need to go to the data source to get the state of the customer entity before anything can happen at all.

Like our inefficient restaurant servers and our unhappy diners, living in a stateless world has its limitations, and for good reason: application state, especially in the cloud, is hard to manage and attractive to push that responsibility elsewhere.

Don’t make state management your database’s problem

Stateless functions have been designed so that the state is always somewhere else–which works fine in some use cases–and ultimately stateless functions require database access for each action taken.

Stateless functions require a database call for each operation, creating an unfortunate precedent for constant round-trips that become increasingly under-performing at large scale.

Above: Stateless functions require a database call for each operation, creating an unfortunate precedent for constant round-trips that become increasingly under-performing at large scale.

  1. Messages get sent to your service?.
  2. In your code, you need to call a database and get the data you need, update it, and store it again?.
  3. After you’re done, you can send messages out again.

So the question becomes: with the milliseconds adding up, how many database round trips can you afford when checking out an online shopper, or updating a household full of IoT devices?

It might sound like a good idea to ignore state and push its responsibility out of the application layer. Sometimes it is; but applications today are becoming increasingly data-centric, which puts purely stateless functions in a tough position because:

  • There are limited data management options - designed for simple functions that use CRUD as the only way to access data
  • Things get slower as the system grows - as services call for more data, performance goes down with each DB connection
  • It’s mostly do-it-yourself (DIY) for event-driven systems - limited OOB support for data models needed for digital twins for IoT, real-time financial services, telemedicine, streaming media and gaming, etc.

More advanced serverless applications can’t afford the round-trip to the database for each data access or storage (as in the image above)–this not only multiplies the cost per event/operation on your cloud platform, but also takes too much time, making it harder to meet latency and performance SLAs.

This means taking ownership of your data by having an efficient, performant, and reliable way of managing, processing, transforming, and enriching data close to the application itself.

In the next part, we look at how the ability to bring stateful services into a serverless architecture powers new types of use cases for advanced enterprise applications.

Learn more in this series




Akka Serverless is now Kalix. Learn more at


The Total Economic Impact™
Of Lightbend Akka Platform

  • 139% ROI
  • 50% to 75% faster time-to-market
  • 20x increase in developer throughput
  • <6 months Akka Platform pays for itself