There is an example where highly distributed, event-driven systems are used. Everyday we are using them. It the cars.

In a car there are many distributed ECUs(1) that communicate in an event driven system. It was tried to use cyclic communication. But all those attempts failed in the long run. Because cyclic communication would required that all the independent ECUs are synced to each other, which is a very hard problem. That is the reason why everybody moved away from cyclic communication.

That said to help the development in automotive a middleware have been developed and used to help the development of such event driven systems. You develop your functions and define how the signals are routed between those functions. The someone later/independent decides on how the functions are distributed on the different ECUs depending the available resources. The middleware then takes care of the correct routing of the signals. Everything is event driven.

(1) Electronic Control Units

Automotive ECUs use cyclic communication and are event driven. ECUs send their signals over CAN at a defined message rate, regardless of whether the state has changed. Other ECUs set up their hardware to monitor the signals they care about, and trigger a hardware interrupt when the signal is received.

ECUs do both cyclic and event-driven, but typically the software logic is event driven, the communication is cyclic.

There's cyclic communication by sending messages over CAN (if reliability doesn't matter that much) or FlexRay (if reliability matters), so if you examine the network, you'll typically see the same PDUs repeat in a cyclic manner. But an individual ECU will handle the bulk of its logic in an event-driven way. An interrupt will trigger for the incoming CAN frame (and that's an event-driven thing!) but a couple of layers up it will most likely just set a flag for what changed, and it will actually be taken care on a logical level when the relevant task's loop runs next time.

> […] and trigger a hardware interrupt when the signal is received.

That is the definition of event driven.

The same is not only true for the CAN-based, and CAN FD-based communication, but also for the Automotive Ethernet-based communication.

There were tries with Time-triggered protocols like TTP/C (used by Daimler for exactly one model) and FlexRay which had cyclic communication. The communication cycle required that the ECUs are synced to the communication cycle because they needed to have to correct data available at exactly their time slot. If they missed the time slot, the data got marked as stale. The same problem on the receiving side.

Electronics can be more trouble than they're worth in cars. If they made modern cars with no electronics in the engine or controls, maybe I'd buy new cars. It's frustrating when my old Cherokee won't start because the antitheft system is having some kind of conniption for example, and I have to go through this ritual of locking and unlocking the doors, reconnecting the battery with the key in the ignition, flipping this mystery switch the previous owner has no clue about but seems to contribute somehow. There's a process to disable this system by buying a new ECU or something but I haven't gotten around to it.

I exclusively drive modern cars, and have never experienced anything along the lines of what you describe. So maybe the problem isn't with modern cars, but old Cherokees ;)

Or you could just get your car fixed

> But using events like this requires a very tight integration between event producer and consumer, so I don't think this will translate well to distributed systems or microservices.

Though I don't think tight integration between event producer and consumer is necessarily antithetical to microservice design. See the consumer-driven contract pattern, for example: https://www.martinfowler.com/articles/consumerDrivenContract...

It's good to hear from an embedded dev. Embedded is so under-represented that people love to argue about things like low level devs don't use them every day.

>> I fully agree with this, also that's still quite common in the embedded world.

Is this why so many gas pumps and ATMs have such horrible delays in their UI?

partially. also, the hardware is generally old. really old. Imagine hardware from the 00's, and there's a good chance that's what's inside the last ATM you used.