title: “Stateful Functions — Event-driven Applications on Apache Flink” layout: base

Stateful Functions is an API that simplifies building distributed stateful applications. It's based on functions with persistent state that can interact dynamically with strong consistency guarantees.

Stateful Functions Applications

A stateful function is a small piece of logic/code existing in multiple instances that represent entities — similar to actors. Functions are invoked through messages and are:

Applications are composed of modules of multiple functions that can interact arbitrarily with:

A Runtime built for Serverless Architectures

The Stateful Functions runtime is designed to provide a set of properties similar to what characterizes serverless functions, but applied to stateful problems.

The runtime is built on Apache Flink®, with the following design principles:

This makes it possible to execute functions on a Kubernetes deployment, a FaaS platform or behind a (micro)service, while providing consistent state and lightweight messaging between functions.

Key Benefits

An Example: Transaction Scoring for Fraud Detection

Keeping track of fraudulent reports

The entry points to the application are the “Fraud Confirmation” and “Transactions” ingresses (e.g. Kafka Topics). As events flow in from “Fraud Confirmation”, the “Fraud Count” function increments its internal counter and sets a 30-day expiration timer on this state. Here, multiple instances of “Fraud Count” will exist — for example, one per customer account. After 30 days, the “Fraud Count” function will receive an expiration message (from itself) and clear its state.

Enriching and scoring transactions

On receiving events from the “Transactions” ingress, the “Transaction Manager” function messages “Fraud Count” to get the current count of fraud cases reported for the customer account; it also messages the “Merchant Scorer” for the trustworthiness score of the transaction merchant. “Transaction Manager” creates a feature vector with the count of fraud cases reported and the merchant score for the customer account that is then sent to the “Model” function for scoring.

Emitting alerts

Depending on the score sent back to “Transaction Manager”, it may emit an alert event to the “Alert User” egress if a given threshold is exceeded.

Learn More

If you find these ideas interesting, give Stateful Functions a try and get involved! Check out the Getting Started section for introduction walkthroughs and the documentation for a deeper look into the internals of Stateful Functions.

GitHub Repository

StateFun Documentation

StateFun Twitter