Event-Driven & Transactional Systems: Models, Architectures & Real-World Use

TAKEAWAYS:

• Event-driven systems react to asynchronous events (e.g., user clicks, sensor data) rather than polling, improving scalability and responsiveness.
• Transactional systems use ACID properties (Atomicity, Consistency, Isolation, Durability) to process critical operations like bank transfers or flight bookings atomically.
• Event-driven architectures (EDA) decouple components via event brokers (e.g., Kafka, RabbitMQ), enabling real-time systems like live sports scores or stock trading.
• Transaction processing systems (TPS) prioritize high throughput and low latency for tasks like order processing (Daraz) or payment settlements (Khalti).
• UML diagrams (sequence, state, activity) model interactions in event-driven systems, while ER diagrams capture transactional data relationships.
• Real-world tie-ins: WhatsApp uses EDA for message delivery; Ncell’s billing system relies on TPS for transactional integrity.

Core Concepts: Event-Driven Systems

Event-driven systems execute actions in response to events (e.g., user input, system notifications, or external triggers). Unlike traditional request-response models, they operate asynchronously, improving efficiency and scalability.

How Event-Driven Systems Work

1. Event Sources: Generate events (e.g., a user clicking a button in eSewa).
2. Event Handlers: Components that process events (e.g., updating a user’s balance).
3. Event Brokers: Middleware (e.g., Kafka, RabbitMQ) that routes events to handlers.
4. Event Consumers: Systems that act on events (e.g., sending a confirmation email).

sequenceDiagram
    participant User as User (eSewa App)
    participant EventBroker as Event Broker (Kafka)
    participant BalanceService as Balance Service
    participant NotificationService as Notification Service

    User->>EventBroker: Event: "Pay Rs. 500"
    EventBroker->>BalanceService: Process Payment
    BalanceService->>EventBroker: Event: "Payment Successful"
    EventBroker->>NotificationService: Send Confirmation
    NotificationService->>User: SMS/Email: "Payment Confirmed"

Key Components of Event-Driven Architectures (EDA)

Real-World Example: Pathao’s Ride-Hailing System

Pathao uses an event-driven architecture to handle:

1. Driver Availability Events: When a driver logs in or becomes available.
2. Ride Request Events: When a user requests a ride.
3. Location Update Events: Real-time GPS updates from drivers.
4. Payment Confirmation Events: After a ride is completed.

stateDiagram-v2
    [*] --> Driver: Logs In
    Driver --> Available: "Availability Event"
    Available --> RideRequest: "User Requests Ride"
    RideRequest --> DriverAssigned: "Pathao Assigns Driver"
    DriverAssigned --> RideInProgress: "Driver Accepts"
    RideInProgress --> RideCompleted: "User Reaches Destination"
    RideCompleted --> [*]: "Payment Processed"

Why EDA?

• Scalability: Handles thousands of concurrent ride requests.
• Decoupling: Drivers and users interact without direct dependencies.
• Real-Time Updates: Live tracking and notifications.

Transactional Systems: Ensuring Data Integrity

Transactional systems process critical operations (e.g., bank transfers, flight bookings) where data consistency is non-negotiable. They rely on ACID properties:

How Transactions Work: A Bank Transfer Example

1. Debit Account A: Rs. 5000 deducted (temporarily locked).
2. Credit Account B: Rs. 5000 added.
3. Commit: Both changes saved permanently.
4. Rollback: If any step fails, both accounts revert.

sequenceDiagram
    participant User as User (NMB Bank App)
    participant BankServer as Bank Server
    participant AccountA as Account A
    participant AccountB as Account B

    User->>BankServer: Transfer Rs. 5000
    BankServer->>AccountA: Debit Rs. 5000 (Lock)
    BankServer->>AccountB: Credit Rs. 5000 (Lock)
    BankServer->>AccountA: Commit
    BankServer->>AccountB: Commit
    BankServer->>User: Confirmation

Event-Driven vs. Transactional Systems: Key Differences

Modeling Event-Driven and Transactional Systems

1. Sequence Diagrams for Event Flows

Show how events propagate through a system. Example: Online Food Ordering (Swiggy):

sequenceDiagram
    participant User as User
    participant Restaurant as Restaurant
    participant OrderSystem as Order System
    participant PaymentGateway as Payment Gateway

    User->>OrderSystem: Place Order (Event)
    OrderSystem->>Restaurant: Notify Chef (Event)
    Restaurant-->>OrderSystem: Order Ready (Event)
    OrderSystem->>PaymentGateway: Process Payment (Event)
    PaymentGateway-->>OrderSystem: Payment Success (Event)
    OrderSystem->>User: Deliver Order (Event)

2. Activity Diagrams for Transaction Workflows

Model step-by-step transaction processes. Example: NEPSE Share Trading:

flowchart TD
    A["User Logs In"] --> B["Select Stock"]
    B --> C["Check Availability"]
    C -->|"Available"| D["Place Order"]
    C -->|"Unavailable"| E["Notify User"]
    D --> F["Debit Account"]
    F --> G["Update Ledger"]
    G --> H["Credit Seller"]
    H --> I["Confirm Trade"]

3. ER Diagrams for Transactional Data

Capture relationships in transactional databases. Example: Khalti’s Transaction System:

erDiagram
    USER ||--o{ TRANSACTION : "makes"
    TRANSACTION ||--|| PAYMENT : "has"
    TRANSACTION ||--|| MERCHANT : "for"
    USER {
        string user_id PK
        string name
        string email
    }
    TRANSACTION {
        string transaction_id PK
        decimal amount
        datetime timestamp
        string status
    }
    PAYMENT {
        string payment_id PK
        string method
        string reference
    }
    MERCHANT {
        string merchant_id PK
        string name
    }

In the Real World

1. WhatsApp (Global)

   • Event-Driven: Uses events like "message sent," "status updated," and "delivery confirmed" to trigger actions (e.g., read receipts, notifications).
   • Transactional: Ensures messages are delivered atomically (no partial sends) and persist even if the app crashes.

2. eSewa (Nepal)

   • Event-Driven: Triggers events for payments (e.g., "payment initiated," "payment failed," "receipt generated").
   • Transactional: Processes payments with ACID compliance to avoid double-charging or lost funds.

3. Ncell Billing System (Nepal)

   • Transactional: Uses TPS to deduct credits from user accounts and update merchant records atomically.
   • Event-Driven: Sends SMS alerts (e.g., "Your balance is low") based on balance update events.

4. Daraz Order Processing

   • Event-Driven: Events like "order placed," "shipment dispatched," and "delivery confirmed" update the system in real time.
   • Transactional: Ensures inventory is deducted only after payment is confirmed (atomic operation).

5. Kathmandu Traffic Management (Smart City Initiative)

   • Event-Driven: Traffic lights change based on real-time sensor events (e.g., "high congestion detected").
   • Transactional: Updates traffic databases atomically to avoid conflicts in route planning.

Worked Example: NTC’s Online Ticket Booking System

Scenario: A user books a bus ticket from Kathmandu to Pokhara via NTC’s website.

Event-Driven Flow:

1. Event: User selects a seat and clicks "Book."
2. Event Broker (Kafka): Routes the event to the booking service.
3. Booking Service: Checks seat availability (transactional).
4. Event: "Seat Confirmed" → Updates user dashboard.
5. Event: "Payment Due" → Triggers payment gateway.
6. Event: "Payment Successful" → Confirms booking.

Transactional Workflow (ACID):

1. Atomicity: Seat is reserved only if payment succeeds.
2. Consistency: Inventory updates and user balance adjust simultaneously.
3. Isolation: No other user can book the same seat during the transaction.
4. Durability: Booking details persist even if the server restarts.

sequenceDiagram
    participant User as User
    participant NTCWebsite as NTC Website
    participant BookingService as Booking Service
    participant PaymentGateway as Payment Gateway
    participant Database as Database

    User->>NTCWebsite: Select Seat & Book
    NTCWebsite->>BookingService: Book Seat (Event)
    BookingService->>Database: Check Availability (Lock Seat)
    Database-->>BookingService: Available
    BookingService->>PaymentGateway: Process Payment (Event)
    PaymentGateway-->>BookingService: Payment Success (Event)
    BookingService->>Database: Commit Booking
    Database-->>BookingService: Confirmation
    BookingService->>NTCWebsite: Show Ticket

Common Challenges and Solutions

Exam Tip

1. Diagrams Are Critical:

   • Sequence Diagrams: Always draw event flows (e.g., "user orders food → restaurant confirms → payment processes").
   • Activity Diagrams: Show transaction steps (e.g., "debit → credit → commit").
   • ER Diagrams: Model transactional data (e.g., User, Transaction, Payment).

2. ACID Properties:

   • Remember the acronym and give one real-world example per property (e.g., "Atomicity: Khalti transfer either completes or rolls back").
   • Explain rollback in transactions (e.g., "If payment fails, the seat is released").

3. Event-Driven vs. Transactional:

   • Event-Driven: Focus on asynchronous, scalable, real-time systems (e.g., notifications).
   • Transactional: Focus on ACID, data integrity, critical operations (e.g., banking).

4. Worked Examples:

   • Always tie to Nepalese apps (eSewa, Daraz, Ncell) or global platforms (WhatsApp, YouTube).
   • Use Kathmandu-specific scenarios (e.g., "traffic light events," "NEPSE trade transactions").

5. Short Notes:

   • For questions like "Test-Driven Development," link it to transactional testing (e.g., "Test payment failure scenarios first").
   • For "Open-Source Development," mention event-driven collaboration (e.g., GitHub issues as events triggering PRs).