Dominik Tornow

One chapter turned out too long for Substack. So I will publish the chapter announcements on Substack and the chapter on Docusaurus

Bonus

Easier to collaborate :)

Even simple examples hide big systems engineering lessons:

Chat Interface

Know what’s ephemeral vs durable

Streaming chunks → ephemeral transport
Complete responses → durable storage

Same origin. Different lifetimes. Different infrastructure.

The DST in @resonatehqio's TS SDK injects failures by pseudo-randomly replacing a character in a message, simulating:

• Invalid format
• Valid format, invalid schema
• Valid format and schema, invalid payload

Simple yet packs a punch

bsky.app/profile/domi...

Sidebar material: Using TLA+ style formulas to describe training & inference:

Training

non-deterministically choose a model from the model space

(wild simplification)

Inference

non-deterministically choose the next token from the top-K predictions

(slight simplification)

Mental model of Large Language Models

{ s ∈ Seq(Tokens) : Len(s) ≤ Max } → [ Tokens → Score ]

A function that maps any sequence of tokens up to the maximum context length to a score for every possible token as the next

train = learn the function
infer = apply the function

A recursive Deep Research Agent with parallel tool calls

➡️ Running on AWS Lambda or Google Cloud Functions
➡️ Doesn’t block your Lambda while waiting

In less than 50 lines of typescript

bsky.app/profile/domi...

What if AWS Lambda could remember?

The new Resonate TypeScript SDK runs stateful computations on stateless infrastructure (AWS Lambda, Azure Functions, GCP Functions)

Coming soon

If you’re building serverless apps, I’d love to get your thoughts before launch

DM me

If you’re building agentic applications, every line hides a systems engineering challenge.

This loop looks simple. It is not.

What’s the first challenge you spot?

bsky.app/profile/domi...

My favorite aspect of LLMs? They are self compositional

infer generates a token.
Applied to itself generates a turn.
Applied to itself generates a conversation.

In other words, inferring the next token drives the entire AI revolution

bsky.app/profile/domi...

My favorite aspect of LLMs? They are self compositional

infer generates a token.
Applied to itself generates a turn.
Applied to itself generates a conversation.

In other words, inferring the next token drives the entire AI revolution

bsky.app/profile/domi...

We will reason about AI & LLMs in terms of two (from our point of view) atomic functions:

train

function train(corpus: Set<Token[]>): Model

Training yields a model

infer

function infer(model: Model, context: Token[]): Token

Inference yields a token

bsky.app/profile/domi...

Distributed Locks are tricky

martin.kleppmann.com/2016/02/08/h...

My take:

bsky.app/profile/domi...

My take:

bsky.app/profile/domi...

But that leaves a critical question:
What should a writer do when it detects a conflict?

(For another thread)

For example:

Writer A reads length(log) = 100
Writer B reads length(log) = 100
Writer A writes Message(exp=101, ...) yields 101
Writer B writes Message(exp=101, ...) yields 102 ❌

Readers ignores messages whose expected index exp does not match their actual index

Solution

You cannot prevent the write, you have to resolve the conflict on read

On startup, a writer W reads the current length of the log, afterwards the writer writes

ind = length(log)

while True:
ind += 1
if append(Message(exp=ind, ...)) != ind:
# conflict detected
...

System Model

A Kafka-like system is a totally ordered, append-only log. Let's think about this system in terms of one operation, append:

append: Log × Msg → Log × Ind

append appends a message Msg to the log and returns the index Ind the message was written to

Requirements

✅ Prevent write conflicts (duh)
✅ Optimize the normal case (one writer)

Ensure correctness in all cases, with minimal overhead in the normal case (no extra reads or writes)

How do you implement single-writer semantics on Kafka-like systems?

In a single-writer system, a write conflict occurs when more than one process acts as the "sole" writer for a given log (partition) at the same time.

Fun distributed systems challenge: How do you implement single-writer semantics on Kafka-like systems?

E.g. S3 support conditional writes: write only if the object doesn’t exist

But Kafka is an append-only log. You can’t prevent writes

So how do you make only one write count?

Chapter 1: AI, Agents, & Agentic Applications

Part 1

Build a sound and complete mental model from first principles

Part 2

Use a minimal agent loop to identify core characteristics and core engineering challenges

Drops end of the month

bsky.app/profile/domi...

[New Book Alert]

Systems Engineering for Agentic Applications

A guide for turning AI-powered prototypes into production-ready agentic applications

Released monthly, chapter by chapter.

If 100 people sign up, we are doing this

agenticapplications.substack.com/about

[New Book Alert]

Systems Engineering for Agentic Applications

A guide for turning AI-powered prototypes into production-ready agentic applications

Released monthly, chapter by chapter.

If 100 people sign up, we are doing this

agenticapplications.substack.com/about

I will never write another book.

I will never write another book.

I will never write another book.

I will never wri—

…

More details coming soon

The printers are warming up. Think Distributed Systems is about to go to press.

From distributed theory to printed reality

www.manning.com/books/think-...

bsky.app/profile/domi...

I do not enjoy the developer experience (stack ripping) of EDA and ES but I am not denying the benefits.

So on an application level, with a large API surface, I avoid. Platform level, with a smaller API surface area, I cave.

What’s your thinking?!

Sounds like a sequential programming model on an event driven execution model 👀

We should chat again sometime soon :)

My take on Event Sourcing

> Event Sourcing to build an application

Hell no

> Event Sourcing to build a platform

Begrudgingly, yes

bsky.app/profile/luke...

Tired

Using callbacks to implement non-blocking I/O

Wired

Using callbacks to implement partial re-execution of transactions that violate serializability, avoiding full aborts

bsky.app/profile/mura...

Programming Languages, Distributed Protocols, and Hollywood Blockbusters

Learn to survive concurrency, distribution, and the zombie apocalypse

Watch my Systems Distributed'25 survival guide

www.youtube.com/watch?v=DW9g...