A program is a collection of loops. Some loops read state. Some loops write state.
The state lives somewhere – a database, Kafka, Redis, a file, memory.
And then other loops wake up and react to that state, and produce new state, and emit it somewhere else. And it keeps happening.
That’s it. That’s all software is.
The code is just the implementation detail of how the loops run. The architecture is really about where the state lives and what happens when a loop falls behind or dies.
When you zoom out
you can also see it everywhere.
A user clicks a button. That’s an event. It ripples through your frontend, hits an API, touches a database, maybe emits to a queue, wakes up some worker, which writes somewhere else, which triggers a notification, which reaches a human, who reacts.
Zoom out further and companies work this way. Markets work this way. Ecosystems.
Events have directionality. They ripple. They hit nodes. The nodes react and emit. The ripple continues.
It’s the same pattern at every scale.
The question
So when I’m stuck on an architecture decision, I ask:
- Where does the state live?
- What loops are reading it?
- What loops are writing it?
- What happens when a loop dies or falls behind?
- What is the required lag between the write and the read?
That’s usually enough to untangle it and get me going again.
This isn’t a formal definition, just a practical lens I’ve found useful
