Menu
Home Explore People Places Arts History Plants & Animals Science Life & Culture Technology
On this page
Event (computing)
Computing operation

In computing, an event is a detectable change or occurrence, such as user input or hardware interrupts, that triggers system responses. Events can be handled synchronously, where the thread is blocked until processing finishes, or asynchronously via mechanisms like the event loop. Implementation methods include callbacks, signals, or interrupts, while event propagation models like bubbling and pub/sub determine how events are distributed. These approaches are fundamental to event-driven systems, providing flexibility and scalability through concepts such as event queueing and complex event processing.

We don't have any images related to Event (computing) yet.
We don't have any YouTube videos related to Event (computing) yet.
We don't have any PDF documents related to Event (computing) yet.
We don't have any Books related to Event (computing) yet.
We don't have any archived web articles related to Event (computing) yet.

Events vs. Messages

In distributed systems, events represent a fact or state change (e.g., OrderPlaced) and are typically broadcast asynchronously to multiple consumers, promoting loose coupling and scalability. While events generally don’t expect an immediate response, acknowledgment mechanisms are often implemented at the infrastructure level (e.g., Kafka commit offsets, SNS delivery statuses) rather than being an inherent part of the event pattern itself.56

In contrast, messages serve a broader role, encompassing commands (e.g., ProcessPayment), events (e.g., PaymentProcessed), and documents (e.g., DataPayload). Both events and messages can support various delivery guarantees, including at-least-once, at-most-once, and exactly-once, depending on the technology stack and implementation. However, exactly-once delivery is often achieved through idempotency mechanisms rather than true, infrastructure-level exactly-once semantics.78

Delivery patterns for both events and messages include publish/subscribe (one-to-many) and point-to-point (one-to-one). While request/reply is technically possible, it is more commonly associated with messaging patterns rather than pure event-driven systems. Events excel at state propagation and decoupled notifications, while messages are better suited for command execution, workflow orchestration, and explicit coordination.910

Modern architectures commonly combine both approaches, leveraging events for distributed state change notifications and messages for targeted command execution and structured workflows based on specific timing, ordering, and delivery requirements.1112

Event Evolution Strategies

In distributed systems, event evolution poses challenges, such as managing inconsistent event schemas across services and ensuring compatibility during gradual system updates. Event evolution strategies in event-driven architectures (EDA) can ensure that systems can handle changes to events without disruption. These strategies can include versioning events, such as semantic versioning or schema evolution, to maintain backward and forward compatibility. Adapters can translate events between old and new formats, ensuring consistent processing across components. These techniques can enable systems to evolve while remaining compatible and reliable in complex, distributed environments.13

Event semaphore

In computer science, an event (also called event semaphore) is a type of synchronization mechanism that is used to indicate to waiting processes when a particular condition has become true.

An event is an abstract data type with a boolean state and the following operations:

  • wait - when executed, causes the suspension of the executing process until the state of the event is set to true. If the state is already set to true before wait was called, wait has no effect.
  • set - sets the event's state to true, release all waiting processes.
  • clear - sets the event's state to false.

Different implementations of events may provide different subsets of these possible operations; for example, the implementation provided by Microsoft Windows provides the operations wait (WaitForObject and related functions), set (SetEvent), and clear (ResetEvent). An option that may be specified during creation of the event object changes the behaviour of SetEvent so that only a single thread is released and the state is automatically returned to false after that thread is released.

Events short of reset function, that is, those which can be completed only once, are known as futures.14 Monitors are, on the other hand, more general since they combine completion signaling with mutex and do not let the producer and consumer to execute simultaneously in the monitor making it an event+critical section.

See also

References

  1. Designing Event-Driven Systems. O'Reilly Media. ISBN 9781492038245. 9781492038245 ↩

  2. Fowler, Martin (2003). Patterns of Enterprise Application Architecture. Addison-Wesley Professional. ISBN 978-0321127426. 978-0321127426 ↩

  3. Designing Event-Driven Systems. O'Reilly Media. ISBN 9781492038245. 9781492038245 ↩

  4. Fowler, Martin (2003). Patterns of Enterprise Application Architecture. Addison-Wesley Professional. ISBN 978-0321127426. 978-0321127426 ↩

  5. Kleppmann, Martin (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media. ISBN 978-1449373320. 978-1449373320 ↩

  6. Building Event-Driven Microservices: Leveraging Organizational Data at Scale. ISBN 978-1492057895. 978-1492057895 ↩

  7. Kleppmann, Martin (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media. ISBN 978-1449373320. 978-1449373320 ↩

  8. Building Event-Driven Microservices: Leveraging Organizational Data at Scale. ISBN 978-1492057895. 978-1492057895 ↩

  9. Kleppmann, Martin (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media. ISBN 978-1449373320. 978-1449373320 ↩

  10. Building Event-Driven Microservices: Leveraging Organizational Data at Scale. ISBN 978-1492057895. 978-1492057895 ↩

  11. Kleppmann, Martin (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media. ISBN 978-1449373320. 978-1449373320 ↩

  12. Building Event-Driven Microservices: Leveraging Organizational Data at Scale. ISBN 978-1492057895. 978-1492057895 ↩

  13. Designing Event-Driven Systems. O'Reilly Media. ISBN 9781492038245. 9781492038245 ↩

  14. 500 lines or less, "A Web Crawler With asyncio Coroutines" by A. Jesse Jiryu Davis and Guido van Rossum says "implementation uses an asyncio.Event in place of the Future shown here. The difference is an Event can be reset, whereas a Future cannot transition from resolved back to pending." http://aosabook.org/en/500L/a-web-crawler-with-asyncio-coroutines.html#fn13 ↩