💡 Real-World Patterns: Notifications & Dashboards

Discover production patterns for event-driven dApps

Listen for smart contract events in real-time

Your Progress

0 / 5 completed

Introduction

Event Filtering

Subscription Management

Real-World Patterns

Key Takeaways

🔨 Production Patterns

Theory meets practice. Every major dApp uses event subscriptions, but each solves different problems. Wallet trackers monitor user activity, price feeds aggregate DEX swaps, NFT platforms track collection transfers, DAOs send governance alerts. The pattern is the same—subscribe, filter, handle events—but the filters and logic differ. Let's explore 4 production-ready patterns used by top protocols.

🎮 Interactive: Pattern Explorer

Select a real-world use case to see its event subscriptions, filters, and implementation details. Study these patterns to understand how production dApps work.

👛 Wallet Activity Tracker

Monitor all incoming/outgoing transactions for a specific wallet. Used by portfolio apps, tax software, and wallet notifications.

📡 Events Monitored

Transfer (ERC20)Mint/Burn (NFT)Swap (DEX)

🔍 Filter Configuration

{
  address: null, // All contracts
  topics: [
    null, // Any event
    "0x000...userAddress", // User is sender (indexed param 1)
    "0x000...userAddress"  // OR user is receiver (indexed param 2)
  ]
}

🎯 Real-World Use Cases

Portfolio trackers (Zapper, DeBank), wallet apps (MetaMask, Rainbow), tax tools (CoinTracker)

💡 Example in Action

When Alice receives USDC, her wallet instantly shows notification: "Received 1000 USDC from Bob"

🏗️ Architecture Best Practices

Event Queue + Background Workers

Don't process events synchronously in WebSocket handler. Push to queue (Redis, RabbitMQ), process in background workers. Prevents blocking, enables retry logic, scales horizontally.

ws.onmessage → Push to queue → Worker picks up → Process → Update DB

Idempotent Event Handlers

Events can be delivered multiple times (reconnections, node issues). Use transaction IDs as unique keys. Check if event already processed before applying changes. IF NOT EXISTS INSERT in SQL.

Exponential Backoff Reconnection

WebSocket dies? Reconnect with increasing delays: 1s, 2s, 4s, 8s, max 30s. Prevents hammering node during outages. Reset delay after successful reconnection.

Multiple RPC Providers (Failover)

Primary fails? Switch to backup provider (Infura → Alchemy → QuickNode). Maintain subscription state, resubscribe on failover. Zero downtime for users.

⚡ Performance Optimization

✓Batch DB writes: Collect 100 events, write once instead of 100 individual writes. Reduces DB load by 100x.
✓Cache frequently accessed data: Current price, token metadata, user balances. Redis in front of DB for sub-millisecond reads.
✓Use indexed DB fields: Index transaction hash, block number, user address. Query performance critical when handling millions of events.
✓Monitor subscription health: Track events/sec, latency, reconnections. Alert if rate drops (indicates filter issue or node problem).

💡 Key Insight

Production event handling is about resilience. WebSocket connections fail. Nodes restart. Networks partition. Your app must handle all of this gracefully. The pattern: filter aggressively (reduce noise) → queue events (decouple processing) → process idempotently (handle duplicates) → reconnect intelligently (exponential backoff). This architecture scales from 10 events/min to 10,000 events/min without code changes. Study how OpenSea, Uniswap, and Etherscan handle events—they all follow these patterns. Your dApp should too. Event subscriptions aren't just about real-time updates—they're about building reliable, scalable infrastructure.

← Subscription Management