The closer to the edge, the more stable a platform must be

Photo by Albert Stoynov on Unsplash.

The closer to the edge, the more stable a platform must be.

The closer a component is to the customer, the greater its responsibility for keeping the entire platform available, even when everything behind it is having a bad day.

Let’s consider a typical platform.

Customer -> Load Balancer -> API Gateway -> Orchestrator -> Microservices -> Database

Every layer has a different job. But every layer also has a different level of responsibility for resiliency.

As you move toward the customer, that responsibility increases.

At the deepest layers of the platform, services are usually focused on business capabilities.

They process orders, transfer money, manage inventory, and store data.

These services often have databases, business rules, stateful operations, and multiple dependencies.

Resiliency matters, but it’s often focused on correctness.

If a database call fails:

• Should the transaction roll back?

• Should the service fail over?

• Should a compensating transaction occur?

These services are primarily concerned with business outcomes.

Move up a layer, and you often find orchestrators and workflow services. These components coordinate work across multiple services.

If one service fails, the orchestrator may retry, execute fallback logic, trigger compensating actions, or roll back a workflow. Their job is not just executing business logic, it’s ensuring execution succeeds despite failures.

At the edge, things change.

Load balancers and API gateways are often stateless, dependency-light, highly available, and extremely fast.

Why?

Because their primary responsibility is availability. Everything behind them is allowed to fail, and they absorb as much of that failure as possible.

They:

• Route around failures

• Shed load

• Fail over traffic

• Enforce timeouts

• Apply retries

• Protect backend systems

The edge isn’t just resilient for itself. It’s resilient on behalf of everything behind it.

The deepest services in a platform should be focused on business logic. The edge should be focused on availability.

The more failures your edge can absorb, the less every downstream service needs to care. That’s why the closer you get to the customer, the more stable the platform must become.

Originally posted on #Bengineering.

If this hit home, share the original with someone who needs it: The closer to the edge, the more stable a platform must be

• Glue Services: Part Two — Data Synchronization
  A useful companion on keeping old and new systems aligned during gradual platform change.

• When modernizing legacy systems, don’t be afraid to build glue services
  Edge translation and isolation patterns pair well with migration-focused architecture decisions.

• YOLO Is a Terrible Strategy for Validating Production Changes
  Operational changes get safer when validation and rollout discipline are part of the design.

• Coding agents can’t see your architecture diagrams—fix that
  Systems thinking improves when design context stays readable, versioned, and close to the code.

• In-Flight Request Tracking: Lessons from Card Payments and HTTP/2
  A deeper look at uncertainty, timeouts, and correctness when distributed requests do not complete cleanly.

• Are Atomic Operations Faster and Better Than a Mutex? It Depends
  A practical reminder that simpler-looking performance choices still need correctness tradeoff analysis.