Event-Driven Architecture Protocols

Event-driven architecture (EDA) is a paradigm shift in how applications communicate and respond to changes.

Why EDA?

Imagine trying to have a conversation where you have to repeatedly ask, “Whats the next sentence?” That’s essentially what traditional polling does. EDA flips this model on its head, allowing applications to react instantly to changes without constant querying.

flowchart TB
    subgraph Traditional["Traditional Polling"]
        direction TB
        C1[Client] 
        S1[Server]
        DB1[(Database)]
        
        C1 -->|1. Poll every n seconds| S1
        S1 -->|2. Query| DB1
        DB1 -->|3. No changes| S1
        S1 -->|4. Empty response| C1
        
        C1 -->|5. Poll again| S1
        S1 -->|6. Query| DB1
        DB1 -->|7. Data changed| S1
        S1 -->|8. Update response| C1
        
        style C1 fill:#f9f,stroke:#333
        style S1 fill:#bbf,stroke:#333
        style DB1 fill:#dfd,stroke:#333
    end
    
    subgraph EDA["Event-Driven Architecture"]
        direction TB
        C2[Client]
        S2[Server]
        DB2[(Database)]
        
        C2 -->|1. Subscribe to events| S2
        DB2 -->|2. Data changes| S2
        S2 -->|3. Push update| C2
        
        style C2 fill:#f9f,stroke:#333
        style S2 fill:#bbf,stroke:#333
        style DB2 fill:#dfd,stroke:#333
    end
    
    %% Add comparison annotations
    classDef note fill:#fff,stroke:#333,stroke-dasharray: 5 5
    N1[Less network traffic]:::note
    N2[Improved responsiveness]:::note
    
    EDA --- N1
    EDA --- N2

Key EDA Protocols

Webhooks

    Webhooks are like having a dedicated courier for your applications. When something important happens, the courier (webhook) delivers the news immediately.

    How it works:

    • Application A subscribes to events from Application B
    • When an event occurs, B sends a HTTP POST to A’s specified endpoint

    Real-world example: An e-commerce platform notifying an inventory management system about new orders.

    Server-Sent Events (SSE)

      SSE is like tuning into a radio station. The client listens, and the server broadcasts updates as they happen.

      How it works:

      • Client establishes a connection using the EventSource API
      • Server sends updates over a single HTTP connection

      Real-world example: A live sports scoreboard updating fans’ browsers in real-time.

      WebSub

      WebSub (formerly PubSubHubbub) is like a town crier system for the web. Publishers announce news to a hub, which then relays it to all interested subscribers.

      Components:

      • Publisher: Creates content
      • Hub: Distributes updates
      • Subscriber: Receives updates

      How it works:

      1. Subscriber discovers hub from publisher
      2. Subscriber sends subscription request to hub
      3. Hub verifies subscription
      4. Hub sends updates to subscriber when publisher posts new content

      Real-world example: A news aggregator getting instant updates from multiple blog platforms.

      Pros:

      • Scalable for many subscribers
      • Decouples publishers and subscribers

      Cons:

      • More complex setup
      • Reliance on hub availability

      WebSocket

      WebSocket provides a full-duplex, persistent connection between client and server. It’s like having an always-open phone line where both parties can speak at any time.

      How it works:

      • Initial handshake upgrades HTTP connection to WebSocket
      • Bidirectional communication can occur freely

      Real-world example: A collaborative document editing platform where multiple users see changes in real-time.

      Pros:

      • True real-time, bidirectional communication
      • Efficient for frequent, small updates

      Cons:

      • More complex to implement
      • May require fallback for older browsers
      flowchart TB
    subgraph Webhooks["Webhooks (HTTP POST)"]
        direction LR
        WA[App A] -->|Step 1: Subscribe| WB[App B]
        WB -->|Step 2: Event occurs|WB
        WB -->|Step 3: HTTP POST| WA
        style WA fill:#f9f,stroke:#333
        style WB fill:#bbf,stroke:#333
    end

    subgraph SSE["Server-Sent Events (SSE)"]
        direction LR
        SC[Client] -->|Step 1: EventSource| SS[Server]
        SS -->|Step 2: Push updates| SC
        SS -->|Step 3: Stream data| SC
        style SC fill:#f9f,stroke:#333
        style SS fill:#bbf,stroke:#333
    end

    subgraph WebSub["WebSub (PubSubHubbub)"]
        direction LR
        Publisher -->|Step 1: Publish| Hub
        Sub[Subscriber] -->|Step 2: Subscribe| Hub
        Hub -->|Step 3: Verify| Sub
        Hub -->|Step 4: Updates| Sub
        style Publisher fill:#dfd,stroke:#333
        style Hub fill:#bbf,stroke:#333
        style Sub fill:#f9f,stroke:#333
    end

    subgraph WebSocket["WebSocket Protocol"]
        direction LR
        WC[Client] <-->|Initial: Upgrade| WS[Server]
        WC <-->|Then: Bidirectional| WS
        style WC fill:#f9f,stroke:#333
        style WS fill:#bbf,stroke:#333
    end

    %% Protocol notes
    classDef note fill:#fff,stroke:#333,stroke-dasharray: 5 5
    N1[Single HTTP POST]:::note
    N2[One-way stream]:::note
    N3[Hub-based distribution]:::note
    N4[Full duplex persistent]:::note

    Webhooks --- N1
    SSE --- N2
    WebSub --- N3
    WebSocket --- N4

      Hybrid Approaches

      Sometimes one size doesn’t fit all. Hybrid approaches combine multiple protocols to create a robust, flexible communication system tailored to specific application needs.

      Why Go Hybrid?

      Think of hybrid approaches as a Swiss Army knife for real-time communication. Each protocol has its strengths, and by combining them, we can address a wider range of scenarios while mitigating individual weaknesses.

      Common Hybrid Strategies

      1. WebSocket + Webhooks

      This combination leverages WebSocket’s real-time capabilities with Webhooks’ server-to-server communication.

      How it works:

      • WebSocket maintains live connections with clients
      • Webhooks handle backend integrations and trigger updates

      Use case: A collaborative project management tool where:

      • Team members see live updates via WebSocket
      • External services (e.g., version control) trigger notifications via Webhooks

      Benefits:

      • Real-time updates for users
      • Seamless integration with third-party services
      1. SSE + WebSub

      This pairing combines SSE’s simplicity for client updates with WebSub’s scalability for content distribution.

      How it works:

      • WebSub handles content distribution to multiple servers
      • SSE delivers updates from servers to end-users

      Use case: A global news aggregation platform where:

      • WebSub distributes articles to regional servers
      • SSE pushes breaking news to users’ browsers

      Benefits:

      • Efficient content distribution
      • Low-latency updates to end-users
      1. WebSocket + SSE

      This approach uses WebSocket for complex, bidirectional communication and SSE for simple, one-way updates.

      How it works:

      • WebSocket handles interactive features
      • SSE manages passive, server-to-client notifications

      Use case: An online gaming platform where:

      • Game actions use WebSocket for real-time interaction
      • Game announcements and global chat use SSE for broadcasting

      Benefits:

      • Optimized resource usage
      • Simplified implementation for different types of updates

      Real-World Example: Financial Trading Platform

      Imagine a platform that combines:

      • WebSockets for live order book updates and trade executions
      • SSE for market news and alerts
      • Webhooks for integrating with banks and payment processors
      • WebSub for distributing research reports to multiple brokers

      This hybrid approach allows the platform to handle various types of data and interactions efficiently, providing a responsive experience for traders while managing backend integrations smoothly.