"Developing applications in a microservice architecture (MSA) is hard. For all the benefits that MSAs bring over monolithic application architectures, they expose developers to all sorts of tough distributed systems problems, making it non-trivial to build applications that are consistent, scalable, and resilient. Building applications in an event-driven way is a great start to get MSA complexity under control, by leveraging the guarantees of logs/message queues (like Kafka) to offload some of the problems. Stream processing systems (KStreams, Flink, etc.) can be powerful tools as well. Their tight integration of state, messaging, and application logic yields strong guarantees, like exactly-once state & event-delivery semantics. However, having been built originally for data processing, those systems cannot easily express business logic with complex control-flow, orchestration tasks, or workflows. Existing systems also have very different operational characteristics compared to stateless service deployments. In this session, we share ideas from a novel system we are developing, called 'Restate'. Our work is inspired by event-sourcing and stream processing systems, but rethought from the ground up for microservices. Restate connects services with each other (and between services and Kafka), and handles crucial aspects like state, communication, failover, and consistency. It does that with a programming model that is crafted not for data processing or analytics, but for services and applications with complex interactions and control flow. The result is an elegant experience of writing applications that are simple, consistent, yet highly resilient and scalable. We believe that Restate complements the current landscape of event-processing systems, by offering a solution for cases where events facilitate control flow and coordination, rather than real-time data processing."

1. 1
Stream Processing…
… but for microservices
Giselle van Dongen Stephan Ewen https://restate.dev/

2. 2

3. 3
The realm of stream processing:
Flink, Kafka, Materialize, and friends

4. 4
The Restate lands!

5. 5
What makes this hard?
Retries/run-to-completion
State consistency
Dual-/multi-write problems
Observability
Complex infra (MQ, KV, Service
Mesh, Workflows Manager, …)
Duplicates / idempotency
Delayed requests/events
Reliable timeouts
Manual state machines,
request races

6. The dangers of not getting this right?
6

7. Every sufficiently complex event-driven app eventually
becomes a (bad) stream processor implementation.
Every sufficiently complex request-based service
eventually becomes a (bad) workflow engine.
7
Greenspan’s (lesser-known) 11th rule:

8. 8
Resilient applications using distributed durable async/await.
Think functions and futures/promises, but distributed
and fault-tolerant.
Powered by a fast, yet lightweight, event-driven foundation

9. 9
service A service B service C
gRPC
HTTP
Kafka
SDK SDK SDK
timers
durable
execution
workflows
reliable
RPC
K/V
store
Restate: An event-broker on steroids

10. Comparison: Event-processing with Kafka
10

11. Comparison: Event-processing with Restate
11

12. Orchestration with Restate
12

13. Orchestration with Restate
13

14. Orchestration with Restate
14

15. Orchestration with Restate
15

16. Orchestration with Restate
16

17. Orchestration with Restate
17

18. Order
status
Restaurant
PoS System
Payment
Provider
driver
customer
Delivery
Driver
pool
order
API
GW
driver-updates Driver
digital twin
Order
workflow
https://demo.restate.dev/
Demo: order processing

19. Order
status
Restaurant
PoS System
Payment
Provider
driver
customer
Delivery
Driver
pool
API
GW
driver-updates Driver
digital twin
https://demo.restate.dev/
Demo: order processing
RPC
durable
side effects
persistent
promises
durable
timers
Order
workflow
Kafka events triggering
serverless workflows
order

20. Example Use Cases for Restate
20
Long-running & low-latency workflows as code
Stateful Serverless apps/services
Microservice orchestration
Background tasks, task queues,
cron jobs
Control planes

21. Revisiting… “Stream Processing is a Protocol”
21
https://twitter.com/jaykreps/status/925761011952467968

22. … but: the protocol should be different
22
How many implementations
of KStreams?
Complexity of large state
(RocksDB), timers,
back-pressure, etc.
PoC stream processing lib for Restate in a few 100s of lines of code.
Limited: Few transformations, low throughput, no back-pressure, no event time.
But: Exactly-once, low latency, large state, zero-downtime upgrades, fast scaling of
compute, dynamic parallelism, state queries, tracing.
How about this protocol:

23. 23
Want to try out Restate? Sign up for beta access:
https://restate.dev/
@restatedev /company/restatedev
Easily build resilient applications
using distributed durable async/await.
● Durable execution, resilient, suspendable
● Stateful and Serverless
● Reliable messaging / RPC
● Persistent Promises to connect systems
● Persistent timers
● SQL over distributed status and state
● Tracing / OTEL
● Bridge Kafka → FaaS
● Bridge Events and RPC world
● Stateful serverless workflows as code
● Resilient microservices / orchestration
● Event-driven applications
● Control Planes