Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Has anyone fully embraced an event-driven architecture?

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 173 posts

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#101

Post by BulgarianIdiot »

rkangel wrote: post #91
BulgarianIdiot wrote: post #85

There's no such architecture, much like there's no "MVC architecture" or "CQRS architecture". These are patterns that should be used specifically in time and space where and when pros outweigh cons. Anyone calling themselves an architect, or an engineer, or even just a "good developer" would acknowledge that interaction patterns and concepts are contextual, not general idioms at the project or system level. Speaking…

I suppose it all depends on your definition of the word architecture. Erlang and Elixir are instantiations of the actor model, which is fundamentally an event driven architecture. It is universally the way that state and side effects are handled in those languages. I touch on it a little bit in another comment: https://news.ycombinator.com/item?id=28047306

Actors are built on async message passing, "events" have a more specific meaning ("X did happen"), therefore it's not correct to say actors are fundamentally EDA.

Aside from the fact many messages in the actor model are not events, but can be commands ("perform X") or queries ("tell me about X") and the difference matters, messages are also not just spit out to no-one-in-particular-and-yet-everyone-who-listens, like it's typical in EDA, but from a specific actor to another specific actor.

To send a message to another actor you need to have their address (or in OOP-ese, their object reference). Sure, you can take one actor and designate it "event hub" and have everyone subscribe to it and then send everything there. But that is NOT a part of the actor model. It's you, writing your own application with your custom logic within it.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#102

Post by altacc »

xet7 wrote: post #4

Monolith is easier to handle. With microservices, any network connection could break, you need a lot more code to handle all that complexity and orchestration.

This depends upon the size & complexity of your monolith & how your development teams work. Essentially it's a trade off about which becomes most work and causes most issues.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#104

Post by EamonnMR »

orekrogue wrote: post #83
EamonnMR wrote: post #28

Much of our codebase is python microservices communicating via Kafka. Once you get past the hurdle of getting kafka connected it's pretty reliable. We have a shared library for producing and consuming so we don't need to reinvent the wheel for new services. We also dump the resulting messages as rows into a database. It works very well.

What do you use to encode the messages? Avro, Proto or maybe just JSON? Most of the books and articles encourage the use of Avro, but I feel like the support in python isn't nearly as good as in other languages. Almost every solution operates on dictionaries instead of classes with annotations which doesn't seem like something you would want to use for a Py project in 2021...

We use Json in our Python projects and Avro in our Java projects. We have considered Avro, CSV, Protobuff or CapnProto for the Python projects but it's never been enough of a win for us to prioritize it. We switched to Pydantic from dictionaries.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#105

Post by PinguTS »

Lucero wrote: post #96
PinguTS wrote: post #61

Earlier quoted context omitted.

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 prob…

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.

> […] 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.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#106

Post by tyingq »

"everybody talks about dead-letter queues but nobody really explains how to handle messages that end up in one"

It varies, but one common example is that the queue is worked by humans. This is pretty common, for example, in travel, for things like accidental overbookings.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#107

Post by ACS_Solver »

Lucero wrote: post #96
PinguTS wrote: post #61

Earlier quoted context omitted.

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 prob…

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.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#108

Post by zzbzq »

Events are a part of any good service-oriented architecture. They can replace patterns that involve batch-ETLing large amounts of data from system to system--events are usually a smoother way of doing the same. They're usually more resource-efficient and responsive than a poll & cache approach. They can also create a more consistent way to broadcast data, avoiding CAP problems from trying to do multiple writes to different systems, and preventing systems from devolving into anti-patterns where a system from a business domain gets misused as a message bus for another system.

Using events into a processing queue is also a good way to make systems more responsive for end-users when compared to making every operation blocking.

Events are not a good replacement for transactional request/response models of (i.e.,, making an API call.) Some people advocate for a "event sourcing" system to create its own internal domain model using events. I don't think this is a good default, but it really comes down to is what tools you're using an how you're used to using them. Namely, you can't have a web service that writes to a RDMBS and then immediately writes to RabbitMQ and call it a consistent system, because the write to RabbitMQ could fail and the systems downstream would be permanently wrong. So event sourcing is used to resolve this into a single-write into a queue system which then forks out into the systems' own RDMBS and also other systems. However the more "normal" way would be to just write this atomically into the RDBMS and have a second process poll it back out into the queue for downstream systems.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#109

Post by BulgarianIdiot »

xet7 wrote: post #4

Monolith is easier to handle. With microservices, any network connection could break, you need a lot more code to handle all that complexity and orchestration.

Monoliths vs. services is like biologists arguing about cells vs. organs.
Post reply on HN