I want to introduce you to Nami.
Nami is a shorthair cat. She is loud, opinionated, aggressively social, and has the prey detection capabilities of something that should not be living in a house catching houseflies mid-air with her bare paws like it's nothing. She still suckles on blankets when she makes biscuits, which is the single most grossly adorable thing I have ever witnessed another living creature do.
She also, I have come to realize, is a perfect implementation of event-driven architecture.
I did not plan to learn a computer science concept from my cat. But here we are.
What event-driven architecture actually is
Most software runs on a schedule or in a loop. Do this, then do this, then check if this happened, then do this again. It's predictable. It's sequential. It does things whether or not anything interesting is happening.
Event-driven architecture is different.1 Instead of running continuously on a schedule, an event-driven system sits idle until something happens — a trigger, a signal, an event — and then responds to it. The system doesn't decide when to act. The world decides, and the system reacts.
The classic example is a user interface. A button doesn't do anything until you click it. The click is the event. The function that runs when you click is the handler. Nothing happens without the trigger.
Nami has been doing this her entire life and frankly she's very good at it.
Nami's event handlers, documented
Event: front door opens
This one has multiple response layers and I want to walk you through all of them because the engineering here is genuinely impressive.
Layer one: Nami detects the door opening from anywhere in the house. I do not know how. The door makes a sound but she responds before the sound finishes. Some kind of pre-emptive interrupt handler.2
Layer two: she sprints toward the door at full speed, because outside is out there and outside is the dream and every open door is a potential portal to the outside and she will not miss it.
Layer three — and this is the part that gets me — if the door closes before she makes it, she does not give up. She sits by the door. She cries at the door. And then, if nobody responds to the crying, she leaves the door, finds a human, makes prolonged eye contact, and physically leads them back to the door.
She implemented a callback function.3 She registered her intent with the door, got no response, and passed the request up the chain to a human who has door-opening permissions. This is not instinct. This is resource escalation logic.
The truly beautiful part is what happens when she actually gets outside. She goes out, looks around, realizes nobody is out there to play with her, and immediately starts crying for you to come outside too. She fought her way through three layers of door-access logic to get outside and her first move is to file a complaint that the outside doesn't have enough people in it.
Honestly same.
Event: fly detected
Handler activates immediately. No deliberation. No warmup. Nami goes from zero to full predator in the time it takes the fly to realize it made a terrible mistake.
She catches them mid-air. With her paws. While they're flying. I have watched her jump and close her paw around a housefly in motion and I genuinely do not understand the physics of it. Her reaction time is faster than mine by a margin that is embarrassing to admit.
In software terms this is a low-latency interrupt handler with extremely tight response time requirements.4 No queuing. No batching. Immediate execution. The fly is the event. The catch is the response. The entire pipeline from detection to completion takes approximately one second.
I have written API endpoints slower than Nami catches flies. This is not a complaint about Nami.
Event: human wakes up / comes home / walks past after a nap reset
This one triggers the signature Nami response: a long, drawn-out, entirely sincere MEEEOOOOOWWWW delivered at a volume that suggests she has not seen you in years and was beginning to give up hope.
She also does a little stretch and flop when she wakes up. Like she's rebooting. Running her startup sequence. Checking all systems before resuming normal operation. The meowing is the startup chime.
What I love about this handler is that it's stateful. Nami tracks how recently she's been pet and socializes accordingly. A fresh nap resets her excitement-to-be-pet meter back to maximum. Every human who walks by after a nap gets the full MEEEOOOOOWWWW experience regardless of how recently she saw them, because from her perspective the nap was a hard reset and the world is new again.
This is exactly how a cache expiry works.5 Time passes, state is cleared, the next request is treated as fresh. Nami's affection has a TTL and it resets on sleep.
Event: it is time to come inside
Nami's error handling is where the architecture gets interesting.
When called inside, Nami does not come inside. Nami initiates evasion protocol. She finds ways to be just far enough away that you can't reach her. She looks directly at you and takes one step sideways. She discovers suddenly that there is a very interesting smell over there, no, over there, no actually over here.
When you finally pick her up — which you have to do, physically, because she has decided that voluntary re-entry is not something she offers — she makes a sound.
The only way I can describe this sound is: Yoshi's death sound effect from Mario.6 "Owowowowowww!!!" Long. Mournful. Betrayed. Like she wasn't just trying to avoid you for five minutes. Like this is a great injustice being visited upon her specifically.
In software terms this is an unhandled exception that throws the loudest possible error before gracefully shutting down.7 She doesn't crash. She complains extensively and then accepts the outcome. Honestly better error handling than a lot of software I've used.
The blanket thing
This one doesn't fit neatly into the event-driven framework and I want to include it anyway because it's important.
When Nami is comfortable and happy she makes biscuits on soft fabric — kneading with her paws, purring, and suckles on the blanket like she did with her mom as a kitten, because soft fabric is comfort and she never fully unlearned it. What a big baby.
There's no computer science parallel here. It's just a small creature doing what makes her feel safe, carrying something tender from her earliest days, and being completely unbothered about it.
I find that more moving than I expected to when I started writing a blog post about event-driven architecture.
What Nami actually taught me
The thing about event-driven systems is that they're responsive in a way that scheduled systems aren't. They don't waste resources doing things when nothing is happening. They don't miss things because they weren't checking at the right moment. They react to the world as it actually is, not as they expected it to be.
Nami doesn't plan her day. She responds to it. Fly appears, she catches it. Door opens, she runs. Human walks by, she announces herself. Blanket is soft, she makes biscuits. The world sends events and she handles them, immediately, with her whole self, every time.
There's something kind of beautiful about that actually. No overhead. No unnecessary processing. Just presence, and response, and a very loud meow to let you know she's paying attention.
She's sitting next to me right now. Not on me — she's a next-to person, not an on-top person, which I respect — just close enough to remind me she's there.
Event: human is typing.
Handler: sit adjacent. Purr occasionally. Supervise.
She's doing great.
Footnotes
1Event-driven architecture is a software design pattern where the flow of a program is determined by events such as user actions, sensor outputs, or messages from other programs. Wikipedia: Event-driven architecture
2In computing, an interrupt is a signal that temporarily halts the current process to handle a higher-priority event. Hardware interrupts respond faster than software polling — similar to how Nami responds before the sound of the door even finishes. Wikipedia: Interrupt
3A callback function is a function passed as an argument to another function, to be executed once a condition is met or an event occurs. Nami escalating from "cry at door" to "go get human" is a textbook callback chain. MDN: Callback function
4Low-latency systems are designed to minimize the delay between an event occurring and a response being produced. High-frequency trading systems, real-time gaming, and apparently Nami's fly-catching reflex all operate in this category. Wikipedia: Latency (engineering)
5TTL (Time To Live) is a value that determines how long a piece of data is considered valid before it expires and must be refreshed. Nami's affection cache has a TTL of approximately one nap. Wikipedia: Time to live
6 If you've never heard it, the sound is worth experiencing for yourself. YouTube: Yoshi death sound effect
7Exception handling is the process of responding to unexpected conditions in a program. Good exception handling communicates the error clearly and recovers gracefully. Nami's Yoshi sound followed by resigned compliance is, architecturally speaking, exemplary. Wikipedia: Exception handling
