Event-Driven Architecture and Smart Contracts

Why the Combination Works

In a traditional event-driven system, an event producer publishes events to a message broker, Kafka, RabbitMQ, AWS EventBridge, and consumers react to those events. The limitation is trust: all participants have to trust the broker operator and the event producers. If a supplier publishes a “goods shipped” event, the buyer takes it at face value because there is no independent verification.

Smart contracts add a verification layer. Instead of trusting that an event happened, you can verify it on-chain. And instead of relying on a consumer’s application to react correctly, the smart contract enforces the reaction deterministically. If goods are confirmed shipped by an IoT sensor oracle, the smart contract releases the escrowed payment. No human approval needed. No room for the buyer to delay payment.

Traditional EDA vs. Blockchain-Enhanced EDA:

Traditional:
  Event ──► Broker ──► Consumer App ──► Execute Business Logic
  (Trust the producer)  (Trust the consumer)  (Trust the execution)

Blockchain-Enhanced:
  Event ──► Oracle ──► Smart Contract ──► Verified Execution
  (Verify via oracle)  (Code is public)    (Consensus guarantees)

Key difference: Trust shifts from institutional to protocol-based

Architecture Pattern

The architecture combines traditional event infrastructure for high-throughput internal processing with blockchain for cross-organizational verification and settlement.

┌──────────────────────────────────────────────┐
│           INTERNAL EVENT BUS (Kafka)          │
│                                               │
│  IoT Events │ ERP Events │ API Events         │
│       │           │            │              │
│       ▼           ▼            ▼              │
│  ┌─────────────────────────────────┐          │
│  │     Event Router / Filter       │          │
│  │  (Internal events stay here)    │          │
│  └──────────────┬──────────────────┘          │
│                 │                              │
│    Cross-org events only                      │
│                 │                              │
│  ┌──────────────▼──────────────────┐          │
│  │     Blockchain Gateway Service   │          │
│  │  - Event → Transaction mapping  │          │
│  │  - Oracle data enrichment       │          │
│  │  - Retry + idempotency          │          │
│  └──────────────┬──────────────────┘          │
└─────────────────┼────────────────────────────┘
                  │
          ┌───────▼───────┐
          │  Smart Contract│
          │  (On-Chain)    │
          │  - Validate    │
          │  - Execute     │
          │  - Emit events │
          └───────┬───────┘
                  │
          On-chain events
                  │
          ┌───────▼───────┐
          │  Event Listener │
          │  (Off-Chain)   │
          │  - React to    │
          │    contract    │
          │    events      │
          └───────────────┘

Solidity Example: Event-Driven Escrow

Consider a freight payment system where the shipper gets paid automatically when IoT sensors confirm delivery at the correct temperature. The smart contract holds payment in escrow and releases it based on oracle-verified delivery events.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract FreightEscrow {
    struct Shipment {
        address shipper;
        address buyer;
        uint256 amount;
        bool delivered;
        bool tempCompliant;
        bool paid;
    }

    mapping(bytes32 => Shipment) public shipments;
    address public oracle;  // Trusted IoT data oracle

    event ShipmentCreated(bytes32 indexed shipmentId, address shipper, uint256 amount);
    event DeliveryConfirmed(bytes32 indexed shipmentId, bool tempCompliant);
    event PaymentReleased(bytes32 indexed shipmentId, address shipper, uint256 amount);
    event DisputeFlagged(bytes32 indexed shipmentId, string reason);

    modifier onlyOracle() {
        require(msg.sender == oracle, "Only oracle can confirm delivery");
        _;
    }

    // Buyer creates shipment and locks payment
    function createShipment(bytes32 shipmentId, address shipper)
        external payable
    {
        require(msg.value > 0, "Payment required");
        shipments[shipmentId] = Shipment(
            shipper, msg.sender, msg.value, false, false, false
        );
        emit ShipmentCreated(shipmentId, shipper, msg.value);
    }

    // Oracle confirms delivery with temperature compliance data
    function confirmDelivery(bytes32 shipmentId, bool tempCompliant)
        external onlyOracle
    {
        Shipment storage s = shipments[shipmentId];
        require(!s.delivered, "Already delivered");

        s.delivered = true;
        s.tempCompliant = tempCompliant;
        emit DeliveryConfirmed(shipmentId, tempCompliant);

        if (tempCompliant) {
            // Auto-release payment, no human approval needed
            s.paid = true;
            payable(s.shipper).transfer(s.amount);
            emit PaymentReleased(shipmentId, s.shipper, s.amount);
        } else {
            emit DisputeFlagged(shipmentId, "Temperature breach during transit");
        }
    }
}

The contract emits events at every state change, ShipmentCreated, DeliveryConfirmed, PaymentReleased. Off-chain systems listen for these events to update dashboards, trigger notifications, and sync with ERPs. The on-chain events become the authoritative event stream that all parties trust.

Listening to On-Chain Events

An off-chain event listener using ethers.js to react to contract events:

const { ethers } = require('ethers');

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const contract = new ethers.Contract(contractAddress, abi, provider);

// Listen for payment release events and update ERP
contract.on('PaymentReleased', async (shipmentId, shipper, amount) => {
    console.log(`Payment released: ${ethers.formatEther(amount)} ETH`);
    console.log(`Shipment: ${shipmentId} → Shipper: ${shipper}`);

    // Trigger ERP invoice settlement via webhook
    await fetch('https://erp.company.com/api/settlements', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            shipmentId: shipmentId,
            amount: ethers.formatEther(amount),
            settledOnChain: true
        })
    });
});

// Listen for disputes that need human intervention
contract.on('DisputeFlagged', async (shipmentId, reason) => {
    console.log(`Dispute: ${shipmentId}, ${reason}`);
    // Alert operations team via Slack/PagerDuty
    await notifyOpsTeam(shipmentId, reason);
});

Design Considerations

Event ordering. Kafka guarantees ordering within a partition. Blockchain guarantees ordering within a block. But events that span both systems, Kafka for internal processing, blockchain for cross-org settlement, can arrive out of order. Your event consumers need to handle idempotency and out-of-order delivery gracefully.

Gas costs for event-heavy contracts. Every emit in Solidity costs gas. On Ethereum mainnet, a contract that emits five events per transaction significantly increases the cost. On layer-2 chains or permissioned networks, this cost is negligible, but it shapes design decisions about event granularity.

Replay and recovery. If your off-chain listener crashes and misses events, you need to replay from a known block height. Ethereum and Fabric both support querying historical events, but your listener must track its last processed block and resume from there. This is not trivial to get right in production.

The combination of EDA and smart contracts is powerful for any workflow where events cross organizational boundaries and need verifiable, automated responses. The key insight is that blockchain is not replacing your event infrastructure, it is adding a trust layer to the events that matter most.