An online store needs to know a product’s price and stock now. A state message records the complete information of interest about that product, rather than just its latest change. A product message can therefore carry its ID, name, price, and stock together. section 3.2.1
# One message per line
{"id": 123, "name": "coffee pad", "price": "10", "stock": 101010}
{"id": 234, "name": "cola", "price": "2", "stock": 52}
{"id": 345, "name": "energy drink", "price": "3", "stock": 42}
Each line is a separate product state message. Notice that price and stock appear together even though one might change without the other. section 3.2.1
A delta carries only changed values, saving repetition but often needing an earlier state to be useful. An event describes what happened, such as a delivery; a state answers what the object looks like. When only the latest state matters, message keys and log compaction can reduce storage. section 3.2.1 section 3.3
State can also be derived from a stream of changes. Replaying messages to find a machine’s latest status or a customer’s balance may be expensive, so stream processing uses techniques such as aggregations and joins. Its results remain intermediate: new messages can arrive, and processing is eventually consistent. section 12.4 section 12.1.2
A relational database is useful for a service’s current state. Kafka retains history from which different services can reconstruct the state their own use cases need. Sharing one database across many services instead risks tightly coupling them. section 17.4.1 section 17.4
