Build Event Driven Architecture (EDA) in Python

Notice: This article is maintained for historical purposes. The Bixly Automate/Nebri OS platform that Bixly built, and this article features, is no longer available. Checkout Serverless Providers as an alternative.

Event Driven Architecture (EDA) is an alternative to Service Oriented Architecture (SOA). Rather than summarizing the pros vs the cons, I would point you to these great resources:


Suffice it to say, I am with Brenda when she says:

… it is more important than ever for business, information, software and technology architects to familiarize themselves with event-driven architecture and consider how a simple “sense, analyze and act” pattern offers a wealth of opportunity.

– Brenda M. Mechelson

What is the best way to accomplish an EDA with Python? It’s natural first that you would want to see the EDA Python Tools currently available. As you might have guessed, we aren’t using any of those because they don’t meet our needs. There’s about a dozen reasons why Python is currently quite bad at being asynchronous which I will have write another article about later. It’s only when you get to scale with multiple threads in Python do you realize it just can’t hang. Even implitmenting various spoolers and queue managers or message brokers, we couldn’t do what we need. Don’t get me wrong, I am a Python fanboy. I have a company (Bixly) to prove it!

The answer for us was to build a fancy Event Driven Architecture Platform. Our back end concurrency is handled with Golang, which plays nicely with Python. We’ve been able to build in all the important features of a platform, while focusing on the Event Driven Architecture.

Now to the crux: How do you build an Event Driven Architecture in Python? It can happen with a surprisingly small amount of programming. Let’s start with the basics:

Getting Events Into The System

Events are triggered from outside the system, and from inside the system. Triggering them from inside the system will become clear later, but getting them into the system can be done by API calls. Assuming you have a Nebri instance, you can send info into the API like so:

This allows your Python script to then handle the payload. I can be anything: html, xml, JSON, TXT, CSV. It just doesn’t matter.  Any incoming message can be turned into a system event of course. That’s done by saving information as a Key Value Pair (KVP) inside of Nebri. Once a KVP is registered in your system, other scripts can react to it. This is the “analyze and act” portion. Think if IFTTT, but handling events with Python.

Handling Events When They Come In

Let’s say we put in a Key Value Pair (KVP) called temperature and we are looking to “act” on that temperature data once it comes into the system. You will write a rule script with the following listener:

class my_class_name(NebriOS):
    listens_to == ['temperature']

Now let’s have our script act if the temperature is above 90 degrees.

class my_class_name(NebriOS):
    listens_to == ['temperature']

    def check(self):
        return self.temperature > 90

    def action(self):

There you have “analyze” and “act” within check() and action().  This is akin to a rule engine, but different in that we aren’t worried about forward/backward chaining as much as reacting to events. Now the chaining is certainly possible on Nebri, but that comes later.

Power And Complexity

You achieve powerful de-coupling when using a EDA. Do you realize that any action can, when the check passes, create other actions? These “events” are thrown into the system and any script that cares can wake and act.

By exposing relevant Domain Events on a shared event bus we can isolate cross cutting functions to separate systems

– Stefan Norberg

Finished Software On EDA

This is fairly new ground. With Nebri you can have a full Web app that is Event Drivin. UI and all.  Until we build in easier mechanism to serve HTML, it’s not extremely easy, but those are coming shortly!

This article will be expanded shortly.