Integration architecture

A small boundary between provider messages and business workflows.

Keep the responsibilities visible

Our proposed architecture has five stages: receive, validate, bind, persist and process. Authentication belongs at the transport boundary. Tenant and device ownership come from trusted configuration. A durable store separates receipt of a message from business effects.

Ghost Signal 0.1 implements pure message normalization only. Its output is an event envelope; it does not operate a network server or provide a hosted ingestion API.

Provider → authenticated receiver → adapter → durable inbox
                                                   ↓
                                rules / history / downstream APIs

Suggested service boundaries

• Integration registry: bind a credential to a tenant and provider application.
• Device registry: bind an allowed DevEUI to a customer site and versioned profile.
• Inbox: persist accepted events with a unique provider identity.
• Processing worker: decode, normalize units and create domain events.
• Outbox: deliver external effects with bounded retries.

Before production

Choose retention limits, expected volume, tenant isolation, recovery objectives and operational owners. Replay representative device fixtures, including malformed and duplicate events. Prove restore and failure recovery in the intended environment.