 | This articleis written like apersonal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings or presents an original argument about a topic. Pleasehelp improve it by rewriting it in anencyclopedic style.(September 2025) (Learn how and when to remove this message) |
Incomputing, anevent is a detectable occurrence or change in state that the system is designed to monitor, such as user input, hardware interrupt, system notification, or change in data or conditions. When associated with an event handler, an event triggers a response. The handler may run synchronously, where the executionthread is blocked until the event handler completes its processing, or asynchronously, where the event may be processed later. Even when synchronous handling appears to block execution, the underlying mechanism in many systems is still asynchronous, managed by theevent loop.[1][2]
Events can be implemented through various mechanisms such ascallbacks, message objects, signals, or interrupts, and events themselves are distinct from the implementation mechanisms used. Event propagation models, such asbubbling, capturing, and pub/sub, define how events are distributed and handled within a system. Other key aspects include event loops, event queueing and prioritization, event sourcing, and complex event processing patterns. These mechanisms contribute to the flexibility and scalability ofevent-driven systems.[1][2]
Indistributed systems, events represent a fact or state change (e.g.,OrderPlaced) and are typically broadcast asynchronously to multiple consumers, promotingloose 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.[3][4]
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.[3][4]
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.[3][4]
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.[3][4]
Indistributed 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 maintainbackward andforward 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.[1]
Incomputer science, anevent (also calledevent semaphore) is a type ofsynchronization mechanism that is used to indicate to waiting processes when a particular condition has become true.
An event is anabstract data type with a Boolean state and the following operations:
Different implementations of events may provide different subsets of these possible operations; for example, the implementation provided byMicrosoft Windows provides the operationswait (WaitForObject and related functions),set (SetEvent), andclear (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 ofreset function, that is, those whichcan be completed only once, are known as futures.[5] Monitors are, on the other hand, more general since they combine completion signaling withmutex and do not let the producer and consumer to execute simultaneously in the monitor making it an event+critical section.
Java DOM Interface EventJavadoc documentationjava.awt.event Java package Javadoc API documentationjavax.swing.eventJava package Javadoc API documentation