Back to blog
eventsreal-timecollaborationarchitecture

Real-Time Collaboration with AuraBoot's Event System

AuraBoot Team|

How AuraBoot's AuraEvent system enables real-time collaboration — from audit trails and notifications to webhooks and cross-module data synchronization.

Real-Time Collaboration with AuraBoot's Event System

Enterprise applications don't exist in isolation. When a sales rep closes a deal, the finance team needs an invoice, the warehouse needs a shipping order, and the manager needs a dashboard update. Traditional architectures handle this with tight coupling or scheduled batch jobs. AuraBoot uses an event system that makes these connections declarative and real-time.

The AuraEvent Architecture

At the heart of AuraBoot's collaboration features is AuraEventBus — a lightweight, transaction-aware event system built on Spring's ApplicationEvent infrastructure.

How It Works

Every data mutation in AuraBoot's command pipeline publishes an event at Stage 18:

User creates Sales Order
  → Command Pipeline processes (Stages 1-17)
  → Stage 18: AuraEvent published
  → Listeners react asynchronously

The key insight: events are published after the transaction commits. This means listeners are guaranteed to see the committed data, not in-flight mutations that might roll back. The publishAfterCommit pattern prevents a common bug in event-driven systems where listeners process events for data that never actually persisted.

Event Structure

Every AuraEvent carries:

{
  "eventType": "RECORD_CREATED",
  "modelCode": "sale_order",
  "recordId": "uuid-here",
  "tenantId": "tenant-uuid",
  "userId": "user-uuid",
  "timestamp": "2026-03-08T10:30:00Z",
  "payload": {
    "customer_id": "...",
    "total_amount": 15000,
    "status": "CONFIRMED"
  },
  "previousValues": null
}

For UPDATE events, previousValues contains the fields that changed, enabling listeners to react only to specific transitions (e.g., status changed from DRAFT to CONFIRMED).

Real-Time Use Cases

1. Cross-Module Data Sync

When an inventory adjustment reduces stock below the reorder point, an event triggers a purchase requisition:

{
  "sideEffects": [
    {
      "type": "CREATE",
      "targetModel": "purchase_requisition",
      "condition": "${quantity < reorder_point}",
      "fieldMap": {
        "product_id": "${product_id}",
        "quantity_needed": "${reorder_point - quantity}",
        "priority": "HIGH"
      }
    }
  ]
}

This is configured in the command DSL — no custom event listener code required.

2. Audit Trails

Every mutation automatically generates an audit log entry (Stage 16 of the command pipeline). This provides:

  • Who: The user who performed the action
  • What: Which fields changed and their previous values
  • When: Precise timestamp
  • Where: The model and record affected
  • Why: The command code that triggered the mutation

Audit logs are immutable and tenant-scoped, meeting compliance requirements for industries like healthcare and finance.

3. Notifications

AuraBoot's notification system subscribes to events and routes alerts based on configurable rules:

  • In-app: Real-time notifications in the web and mobile UIs
  • Email: Digest or immediate email alerts
  • Webhook: Push to external systems (Slack, Teams, custom endpoints)

Notification rules are configured per model and event type, so you can set up "notify the sales manager when an opportunity exceeds $50K" without writing code.

4. Dashboard Refresh

Dashboards and stat cards in AuraBoot use Named Queries with Redis caching. When a relevant event fires, the cache is invalidated (Stage 17), and the next dashboard load fetches fresh data.

This means a KPI dashboard showing "Total Revenue This Month" updates within seconds of a new order being confirmed — without polling or manual refresh.

5. Webhook Dispatch

For integrating with external systems, events can be forwarded as webhooks:

{
  "webhooks": [
    {
      "url": "https://your-erp.com/api/orders",
      "events": ["sale_order:RECORD_CREATED", "sale_order:RECORD_UPDATED"],
      "headers": { "Authorization": "Bearer ${WEBHOOK_SECRET}" }
    }
  ]
}

The webhook dispatcher handles retries, exponential backoff, and dead-letter queuing for failed deliveries.

Instant Messaging Integration

AuraBoot includes a built-in IM system with WebSocket-based real-time messaging. The IM module supports:

  • Conversations: One-to-one and group chats
  • Sequence-based sync: A single mechanism handles multi-device sync, offline message delivery, and read receipts
  • Structured messages: Beyond text, messages can contain record cards, approval requests, and AI agent responses

The IM system integrates with the event bus — creating a record can automatically post a message to a team channel, and approvals can be initiated directly from a chat message.

WebSocket Protocol

The IM system uses a custom WebSocket protocol at /api/im/ws:

Client → Server: SEND (message payload)
Server → Client: SEND_ACK (message id, sequence)
Server → Client: SYNC_RESULT (missed messages)
Server → Client: READ_RECEIPT (conversation, last_read_seq)
Client → Server: TYPING (conversation id)

Each message gets a monotonically increasing sequence number per conversation, enabling efficient sync: "give me everything after sequence 42."

Event-Driven vs Request-Driven

Traditional request-driven architectures create coupling:

OrderService.createOrder() {
    orderRepo.save(order);
    invoiceService.createInvoice(order);  // coupled
    inventoryService.reserve(order);       // coupled
    notificationService.notify(order);     // coupled
    analyticsService.track(order);         // coupled
}

Adding a new integration means modifying OrderService. Testing requires mocking five dependencies. Failures cascade.

AuraBoot's event-driven approach decouples these concerns:

CommandPipeline: Create Order
  → Stage 11: Save to DB
  → Stage 13: Side Effects (invoice, inventory)
  → Stage 18: Publish Event
      → NotificationListener: Send alert
      → WebhookListener: Forward to external ERP
      → AnalyticsListener: Track metrics

Adding a new listener requires zero changes to the command or pipeline. Each listener can fail independently without affecting the primary operation.

Building Custom Event Listeners

For cases where the declarative DSL isn't enough, you can write custom Java listeners:

@Component
public class CustomOrderListener {

    @EventListener
    @Async
    public void onOrderCreated(AuraEvent event) {
        if (!"sale_order".equals(event.getModelCode())) return;
        if (event.getEventType() != EventType.RECORD_CREATED) return;

        // Custom logic here
        BigDecimal amount = event.getPayload().get("total_amount");
        if (amount.compareTo(new BigDecimal("100000")) > 0) {
            // Escalate to VP of Sales
        }
    }
}

Custom listeners are asynchronous by default and run outside the original transaction.

Conclusion

AuraBoot's event system helps business applications move beyond isolated data tables. Side effects, notifications, webhooks, cache invalidation, and real-time messaging all flow from the same event architecture — configured declaratively through the DSL and extensible with custom code when needed.

The result: when one person takes an action, everyone who needs to know finds out immediately, every downstream system updates automatically, and every change is audited.

Explore related command and event patterns in our command documentation or try it yourself with the getting started guide.