Contributors Guide to the Code

Module Overview

Defines the Faust application: configuration, sending messages, etc.


Command-line interface.


All custom exceptions are defined in this module.


Models describe how message keys and values are serialized/deserialized.


Sensors record statistics from a running Faust application.


Serialization using JSON, and codecs for encoding.


Table storage: in-memory, RocksDB, etc.


Stream and table implementation.


Creating topic descriptions, and tools related to topics.


Message transport implementations, e.g. aiokafka.


Public interface for static typing.


Utilities. Note: This package is not allowed to import from the top-level package.


Web abstractions and web applications served by the Faust web server.

Windowing strategies.


Deployment helper for faust applications: signal handling, graceful shutdown, etc.


Everything in Faust that can be started/stopped and restarted, is a Service.

Services can start other services, but they can also start asyncio.Task via self.add_future. These dependencies will be started/stopped/restarted with the service.


The worker can be used to start a Faust application, and performs tasks like setting up logging, installs signal handlers and debugging tools etc.


The app configures the Faust instance, and is the entry point for just about everything that happens in a Faust instance. Consuming/Producing messages, starting streams and agents, etc.

The app is usually started by Worker, but can also be started alone if less operating system interaction is wanted, like if you want to embed Faust in an application that already sets up signal handling and logging.


The monitor is a feature-complete sensor that collects statistics about the running instance. The monitor data can be exposed by the web server.


The producer is used to publish messages to Kafka topics, and is started whenever necessary. The App will always starts this when a Faust instance is starting, in anticipation of messages to be produced.


The Consumer is responsible for consuming messages from Kafka topics, to be delivered to the streams. It does not actually fetch messages (the Fetcher services does that), but it handles everything to do with consumption, like managing topic subscriptions etc.


Agents are also services, and any async function decorated using @app.agent will start with the app.


The topic conductor manages topic subscriptions, and forward messages from the Kafka consumer to the streams. will iterate over the topic: aiter(topic). The conductor feeds messages into that iteration, so the stream receives messages in the topic:

async for event in stream(event async for event in topic)


Manages tables, including recovery from changelog and caching table contents. The table manager also starts the tables themselves, and acts as a registry of tables in the Faust instance.


Any user defined table.


Every table has a separate store, the store describes how the table is stored in this instance. It could be stored in-memory (default), or as a RocksDB key/value database if the data set is too big to fit in memory.


These are individual streams, started after everything is set up.


The Fetcher is the service that actually retrieves messages from the kafka topic. The fetcher forwards these messages to the TopicManager, which in turns forwards it to Topic’s and streams.


This is a local web server started by the app (see web_enable setting).