Edge computing isn’t “the cloud, but farther away.”
It’s an environment where your assumptions break:
- networks flap,
- devices roam,
- power cycles happen,
- and “just retry” turns into a thundering herd.
If you’re building edge → core systems, your job isn’t just shipping messages. It’s making sure your architecture still behaves when reality shows up.
Bruno Baloi’s Living on the Edge: Eventing for a New Dimension is a practical guide that lays out the constraints and the patterns to handle them.
The four constraints you can’t ignore
1) Connectivity is a spectrum, not a boolean
At the edge, connectivity is:
- intermittent,
- asymmetric,
- and sometimes intentionally limited (cost/coverage/roaming).
Your system needs to tolerate “offline-first” stretches without collapsing into retry storms.
2) Security isn’t perimeter-based anymore
Edge deployments are physically exposed. “Trusted network” assumptions don’t survive:
- compromised devices,
- injected traffic,
- misconfigured gateways.
Treat edge and core as different trust realms.
3) Distribution becomes an architecture problem (not an app problem)
If you broadcast everything everywhere, you pay for it:
- bandwidth,
- CPU,
- operator sanity.
You need deliberate routing and shaping — not a blob of ad-hoc glue services.
4) Observability has to work across boundaries
At the edge, you’ll debug:
- gaps,
- bursts,
- delayed delivery,
- partial partitions.
If you can’t trace signals end-to-end, you’re operating blind.
A useful mental model: edge and core are different realms
One of the strongest architectural reframes:
Don’t treat edge as a distant region of the same system.
Treat it as a separate operational realm, connected by controlled paths.
That means designing for:
- async boundaries,
- store-and-forward,
- explicit policies about what crosses realms.
When thinking through these concepts in your next design review, hopefully this checklist will be helpful:
- Do we have a bounded set of subjects/topics that cross edge → core?
- Can we operate during extended offline conditions?
- Do reconnects create burst floods?
- Is backpressure handled centrally (policy) vs scattered per-service?
- Can we trace a signal across the edge boundary?
If those questions make you slightly uncomfortable, you’ll get value out of the white paper.
Check it out: https://www.synadia.com/resources/living-on-the-edge
Top comments (0)