The Stoics had a deceptively simple framework for navigating uncertainty: divide everything into two buckets — what is within your control, and what is not. Epictetus called this the dichotomy of control, and it sits at the heart of Stoic practice. What surprises most engineers is how cleanly this maps onto the discipline of cloud architecture.

What You Control in the Cloud

When you design a system on AWS, you control the architecture. You choose the service boundaries, the retry logic, the circuit breakers, the IAM policies, the encryption at rest and in transit. You decide whether your Lambda functions are idempotent, whether your SQS queues have dead-letter queues, whether your RDS instances have Multi-AZ failover enabled.

These are your hegemonikon — your governing faculty. They are the decisions that determine how your system behaves when the world does not cooperate.

What You Do Not Control

You do not control an AWS availability zone going dark. You do not control a dependency’s API rate limits, a BGP route flap, or a cascading failure in a shared service. You do not control the traffic spike that arrives at 2 AM on a Tuesday.

The Stoic response is not to pretend these events won’t happen. It is to design as if they will.

Designing for the Uncontrollable

This is where the dichotomy becomes an engineering discipline. Every architectural decision should be evaluated through the lens of: what happens when this fails?

  • Multi-region active-active is not paranoia — it is the acknowledgment that a single region is outside your control.
  • Exponential backoff with jitter is not boilerplate — it is the recognition that downstream services will occasionally be unavailable.
  • Dead-letter queues are not edge-case handling — they are the acceptance that some messages will fail, and that failure deserves a deliberate response.

The Practical Outcome

Teams that internalize the dichotomy of control stop arguing about whether failures will happen and start designing for when they do. They write runbooks before incidents, not after. They conduct chaos engineering exercises not to prove their system is perfect, but to discover its failure modes while the stakes are low.

The Stoic architect does not build a system that never fails. They build a system that fails gracefully, recovers automatically, and surfaces the right signals when human judgment is required.

That is the only kind of control worth having.