Loading learning content...
The question is never "edge or origin?"—it's "what belongs where?"
Every distributed system must partition workloads across the available compute topology. In edge-enabled architectures, this topology spans from user devices through edge locations to centralized cloud. The art of edge architecture is drawing the right lines—placing each computation at the location that optimizes for the constraints that matter most for that specific operation.
This page develops the decision framework for workload placement, explores hybrid architecture patterns that combine edge and origin processing, and addresses the practical challenges of operating across the cloud-to-edge continuum. By the end, you'll be equipped to partition any application's workloads across the distributed topology effectively.
By the end of this page, you will understand the fundamental trade-offs that determine optimal workload placement, specific patterns for hybrid edge-origin architectures, techniques for workload partitioning and migration, consistency and coordination strategies across distributed locations, and operational considerations for hybrid systems.
Workload placement decisions navigate a multi-dimensional trade-off space. Understanding these dimensions is prerequisite to making informed placement decisions.
| Factor | Edge-Favoring | Origin-Favoring |
|---|---|---|
| Latency Need | Sub-50ms required | Seconds acceptable |
| Data Volume | High (reduce transmission) | Low (send to origin) |
| Computation Complexity | Simple transforms/filters | Heavy ML, complex logic |
| State Requirements | Stateless or local | Global coordination needed |
| Service Integrations | Self-contained | Multiple cloud services |
| Consistency Model | Eventual acceptable | Strong required |
| Failure Tolerance | Must work offline | Cloud connectivity required |
| Update Frequency | Stable logic | Rapidly changing requirements |
When in doubt, start with this heuristic: Place workloads at edge only when latency constraints require it OR when bandwidth reduction provides clear economic benefit. Default to origin for everything else—it's operationally simpler. Move workloads to edge incrementally as you prove the value.
To reason about placement, visualize the complete request journey from user to origin and back. Each point in this journey is a potential processing location with different characteristics.
The Request Journey Stages:
User Device → ISP Network → Edge PoP → Internet Backbone → Origin Region → Application Servers → Database
↓ ↓ ↓ ↓ ↓ ↓ ↓
1ms 5ms 10ms 100ms 200ms 210ms 230ms
(cumulative latency from user)
At each stage, we can intercept, process, cache, or forward the request. The closer to the user we can satisfy the request, the lower the latency—but the fewer resources and capabilities available.
Request Journey Decision Points:
For each incoming request, the system decides at each layer: process here, forward, or reject?
Most optimization should focus on the hot path—the request patterns that represent 80%+ of traffic. Typically this is content serving, not transactions. If you can satisfy 90% of requests at the edge, the 10% that must reach origin can tolerate higher latency without impacting overall user experience.
Production edge deployments rarely put everything at edge or everything at origin. Instead, they employ hybrid patterns that distribute responsibilities appropriately. Here are the proven patterns:
In hybrid architectures, data flows between edge and origin. How you manage this flow determines consistency, latency, and system complexity. Here are the key synchronization strategies:
| Requirement | Recommended Strategy | Trade-offs |
|---|---|---|
| Read latency critical, stale OK | Push replication + periodic sync | Origin compute for change detection |
| Read consistency critical | Pull-through with short TTL | Cold request latency |
| Write latency critical | Write-behind async | Risk of data loss, conflict handling |
| Write consistency critical | Write-through synchronous | Write latency includes origin RTT |
| Offline operation needed | Local-first with CRDT merge | Conflict resolution complexity |
| High write volume | Batch write-behind | Higher eventual inconsistency window |
When edge and origin can both modify state, conflicts are inevitable during network partitions or concurrent access. Design for this from the start: use CRDTs for automatic merge where possible, last-writer-wins for simple cases, or application-specific merge logic for complex domains. Conflicts that reach production without a resolution strategy cause data corruption or loss.
Given an existing application, how do you systematically identify what belongs at edge versus origin? This methodology provides a structured approach:
Step 1: Request Inventory
Catalog all request types in your application:
Step 2: Latency Impact Analysis
For each request type, quantify the impact of latency:
Step 3: Dependency Mapping
For each edge candidate, analyze what it needs:
Step 4: Partition Design
Group requests into processing tiers:
Step 5: Migration Sequencing
Prioritize edge migration by impact:
Don't attempt to edge-optimize everything at once. Each migration step should be independently measurable and reversible. Deploy edge logic behind feature flags, measure impact, and roll back if issues arise. Accumulate edge capabilities progressively rather than attempting a big-bang migration.
Edge computing forces explicit decisions about consistency. When data is replicated to hundreds of locations, strong consistency becomes expensive or impossible. Understanding consistency models helps you choose appropriately for each use case.
| Use Case | Recommended Model | Rationale |
|---|---|---|
| Inventory for add-to-cart | Bounded staleness (5 min) | Stale OK for display; verify at checkout |
| Payment processing | Strong consistency | Cannot double-charge or oversell |
| Feature flags | Eventual consistency | Seconds of staleness acceptable |
| User session/cart | Read-your-writes | User's changes visible immediately to them |
| Collaborative document | Causal consistency | Edits must be ordered correctly |
| Content personalization | Eventual (30 second) | Near-real-time personalization sufficient |
Edge computing is inherently a distributed system across unreliable networks. The CAP theorem applies: during network partitions, you must choose between consistency and availability. Most edge systems choose availability (continue serving from cache) and accept bounded inconsistency. Design your edge layer to degrade gracefully, not fail completely, when origin connectivity is lost.
Operating edge-origin hybrid systems introduces unique challenges not present in purely centralized architectures. Teams must adapt their operational practices:
Edge introduces failure modes that don't exist in centralized systems: edge-specific outages, edge-origin connectivity loss, inconsistent edge state. Conduct chaos engineering at the edge: disconnect edge locations, inject latency between edge and origin, corrupt edge cache. Verify graceful degradation before production incidents reveal gaps.
We've developed the framework for partitioning workloads between edge and origin—from the fundamental trade-offs to the practical operational considerations. Let's consolidate:
What's Next:
The final page of this module addresses edge data challenges—the unique difficulties of managing state at the edge, from caching invalidation to data sovereignty, and the architectural patterns that address these challenges.
You now have a comprehensive framework for edge vs. origin workload placement. You understand the trade-off dimensions, architectural patterns, synchronization strategies, and operational considerations for hybrid edge-origin systems. Next, we'll address the specific challenges of managing data at the edge.