Skip to main content

The RCOM Gateway Architecture

The RCOM Gateway is built on a fully event-driven architecture. The system reacts immediately to real-world signals coming from devices, applications, or internal triggers. Every action inside the platform begins with an event, flows through a well-defined processing path, and produces a consistent, predictable outcome.

This article explains how the Gateway is structured internally, how events move through the system, and why this architecture allows the platform to scale reliably across different industries and deployment sizes.

The Event-Driven Architecture at a Glance​

The Gateway is designed around a simple but powerful idea:

Everything is an event

A tag read, a barcode scan, a sensor update, a workflow timer, an API call, a map interaction, or even an object being updated inside the system - each of these actions is treated as an incoming event that must be processed immediately and consistently.

This model gives the platform:

  • low latency,
  • predictable behavior,
  • natural scalability,
  • resilience under heavy load,
  • and a unified processing flow regardless of data source.

Core Components of the Architecture​

Event Sources​

Events can enter the Gateway from many channels:

  • REST API Endpoints – synchronous or asynchronous ingestion
  • MQTT Topics – ideal for high-frequency IoT and Auto-ID traffic
  • Object Change Events – triggered when stored data is created, updated, or deleted
  • Scheduler Events – timers, intervals, and delayed execution
  • Custom UI Interactions – user actions triggering workflows

Regardless of the channel, all incoming data is normalized into a unified internal event format.

Event Processor Layer​

Before an event reaches a workflow, it passes through an EventProcessor, which acts as the routing and filtering layer.

An EventProcessor determines:

  • Which workflow should run?
  • Under what conditions should it run?
  • What fields should be extracted and mapped?
  • Which events should be ignored?

This decoupling allows you to change routing logic without modifying workflows themselves.

Workflow Execution Engine​

Once an event is accepted, the WorkflowEngine takes over.

It executes your logic step by step:

  • Extract fields from the incoming payload
  • Evaluate conditions
  • Transform data
  • Query or update ObjectGroups
  • Call external APIs
  • Publish MQTT messages
  • Create or modify files
  • Trigger other workflows
  • Update user interfaces

The engine is built to run thousands of workflows in parallel, making it suitable for high-volume Auto-ID deployments.

Object Group Storage Layer​

ObjectGroups act as the platform’s structured storage layer, maintaining digital twins of real-world entities.

They enable:

  • consistent state management
  • versioning and history tracking
  • workflow-driven updates
  • efficient lookups during processing
  • clean integration with maps and dashboards

This storage layer is optimized for event-driven workloads where objects may update frequently.

Integration Layer​

The Gateway includes built-in methods for communicating with external systems:

  • REST calls (inbound and outbound
  • MQTT publish/subscribe
  • File creation (XML, Excel)
  • SQL queries

Workflows use these connectors to push cleaned, structured data to your ERP, WMS, MES, cloud services, or custom applications.

How Events Flow Through the System​

The typical event lifecycle looks like this:

  1. Event arrives via REST/MQTT/EPCIS/UI/Scheduler.
  2. EventProcessor filters and routes it to the correct workflow.
  3. Workflow extracts data, validates it, and applies business logic.
  4. ObjectGroups update to reflect new state (optional).
  5. External systems receive structured outputs via API calls, files, or MQTT.
  6. Maps and UIs refresh with updated real-time data.
  7. Logs and job history record the full execution trace for auditing.

Because the system is asynchronous and distributed internally, large spikes in device activity do not slow down processing.

Why This Architecture Scales​

The event-driven model makes the Gateway naturally scalable:

  • High throughput – events can be processed in parallel across multiple workflow runners.
  • Fault isolation – one failing workflow does not block others.
  • Decoupling – event sources, processors, workflows, and storage evolve independently.
  • Horizontal expansion – multiple Gateway instances can share load in large deployments.
  • Edge offloading – Agents filter noise upstream, reducing unnecessary load on the Gateway.

This enables deployments ranging from small single-site operations to global networks with thousands of devices and millions of events per day.

Related Articles