Architecture

N-Hub is built with a layered architecture that separates how data enters the platform, how it is processed, and how it is accessed.

Platform Layers

graph TB
    subgraph Devices["Devices & Networks"]
        D1[IoT Sensors]
        D2[LoRaWAN Gateways]
        D3[Network Servers]
    end

    subgraph Ingestion["Ingestion Layer"]
        I1[HTTP Webhooks]
        I2[MQTT Bridge]
        I3[LoRaWAN Connector]
    end

    subgraph Processing["Processing Layer"]
        P1[Deduplication]
        P2[Device Resolution]
        P3[Payload Decoding]
        P4[Data Validation]
    end

    subgraph Storage["Storage Layer"]
        S1[Device Registry]
        S2[Time-Series Readings]
        S3[Configuration & Metadata]
    end

    subgraph Access["Access Layer"]
        A1[Web Portal]
        A2[REST API]
        A3[MQTT Streaming]
    end

    D1 --> I2
    D2 --> D3
    D3 --> I1
    D3 --> I3
    I1 --> P1
    I2 --> P1
    I3 --> P1
    P1 --> P2
    P2 --> P3
    P3 --> P4
    P4 --> S1
    P4 --> S2
    S1 --> A1
    S2 --> A1
    S1 --> A2
    S2 --> A2
    S2 --> A3

Layer Descriptions

Ingestion Layer

The platform accepts device data through multiple protocols:

Protocol	Use Case
HTTP Webhooks	Network servers and third-party systems push data via POST requests
MQTT	Devices and gateways publish data directly over MQTT with TLS (certificate or username/password auth)
LoRaWAN Connector	Native integration with ThingPark Wireless for LoRaWAN device and base station data

All ingestion endpoints return immediately after accepting a message. Processing happens asynchronously, so upstream systems are never blocked by downstream processing time.

Processing Layer

Every incoming message passes through a processing pipeline:

1. Deduplication — identical messages (e.g., from network server retries) are detected and dropped
2. Device resolution — the device is identified from the message payload and matched against the registry
3. Payload decoding — the active parser (JavaScript) converts raw bytes into structured readings
4. Data validation — decoded readings are validated before storage

Exactly-once processing

The deduplication layer ensures each device message is processed exactly once, even if the upstream source delivers duplicates. This is critical for accurate sensor readings and billing.

Messages that fail processing (unknown device, parser error) are automatically retried with backoff. Persistent failures are logged with full diagnostic details.

Storage Layer

Processed data is stored across purpose-built stores:

• Device registry — device metadata, configuration, and status
• Time-series readings — decoded sensor values indexed by device and timestamp, optimized for range queries
• Configuration — enterprises, sites, parsers, user assignments

Access Layer

Stored data is available through multiple interfaces:

Interface	Description
Web Portal	Dashboard for managing devices, viewing readings, configuring parsers
REST API	Programmatic access to all platform data and configuration
MQTT Streaming	Real-time data subscriptions with X.509 certificate authentication

Multi-Tenancy

Each enterprise (organization) on the platform has fully isolated:

• Data — device readings, messages, and configuration are scoped per enterprise
• Users — access is controlled by email domain and role-based permissions
• Devices — device registrations belong to a single enterprise
• Parsers — parser versions are managed independently per enterprise and device type

Cross-tenant access

Cross-tenant data access is not possible through any customer-facing interface. All queries are filtered by enterprise, and MQTT subscriptions are scoped to the authenticated enterprise.

High Availability

The platform is designed for continuous operation:

• Redundant compute — application instances run across multiple availability zones with automatic failover
• Asynchronous processing — ingestion and processing are decoupled, so traffic spikes don't affect data access
• Automatic retries — transient failures in processing are retried with exponential backoff
• Retry with backoff — failed messages are retried automatically; persistent failures are logged for investigation