Part 1: The Six Survival Instincts
Before any technique, before any pattern, before any buzzword, there are instincts. A chinchilla doesn’t read a textbook on predator avoidance. It has instincts.
Good system design has exactly six instincts. Every pattern, every algorithm, every architecture decision traces back to one of these. Learn these six and you can DERIVE the rest.
Instinct #1: REMEMBER
Section titled “Instinct #1: REMEMBER”The problem: A chinchilla stashes 200 seeds across the mountain in October. January comes. Snow covers everything. If the chinchilla doesn’t remember where the seeds are, it starves.
The principle: Systems must remember their state across time. Crashes, restarts, power outages: when the system comes back, it needs to know what happened before.
This covers:
- Persistence & durability
- Checkpointing & recovery
- Stateful vs stateless design
- Write-ahead logs
- Session management
- Disaster recovery
The instinct question: “If this system crashes right now and restarts, what is lost?”
If the answer is “something important,” you have a Remember problem.
Instinct #2: AGREE
Section titled “Instinct #2: AGREE”The problem: Two chinchillas both think they own the same seed. They fight. The seed rolls off the ledge. Nobody gets it.
The principle: All parts of a system must agree on what the truth is. When they disagree, things break: silently, dangerously, and in ways that are hard to debug.
This covers:
- Consistency models (strong, eventual, causal)
- Consensus algorithms (Paxos, Raft)
- Distributed transactions
- Conflict resolution
- Idempotency
- Single source of truth
The instinct question: “Can two parts of this system believe different things at the same time?”
If yes, you have an Agree problem.
Instinct #3: SURVIVE
Section titled “Instinct #3: SURVIVE”The problem: An eagle swoops down on the colony. The chinchilla that freezes in the open dies. The chinchilla that has an escape tunnel lives.
The principle: Systems must continue operating when things fail. Not “if” things fail: “when.” Hardware dies. Networks split. Software has bugs. The question is: does the system handle it gracefully, or does it fall over?
This covers:
- Fault tolerance & redundancy
- Circuit breakers
- Graceful degradation
- Failover & health checks
- Blast radius containment
- Chaos engineering
The instinct question: “What’s the worst thing that could fail, and what happens to users when it does?”
If the answer is “everything breaks,” you have a Survive problem.
Instinct #4: PROTECT
Section titled “Instinct #4: PROTECT”The problem: A researcher tags a chinchilla with a GPS tracker. Now every predator on the mountain can find it. The chinchilla didn’t consent to being tracked.
The principle: Systems must protect user data, control access, and never expose more than necessary. Security and privacy aren’t features: they’re foundations.
This covers:
- Authentication & authorization
- Encryption (at rest, in transit)
- Input validation
- Rate limiting (abuse prevention)
- Privacy by design
- Secret management
- Principle of least privilege
The instinct question: “Who can see this data, and did they explicitly ask to share it?”
If you’re not sure, you have a Protect problem.
Instinct #5: SUSTAIN
Section titled “Instinct #5: SUSTAIN”The problem: One chinchilla tries to carry 50 seeds at once. It can carry 2. It drops 48. Then it has to go back and pick them all up again. It would have been faster to make 25 trips of 2.
The principle: Systems have limited resources: CPU, memory, bandwidth, storage, time. Every design choice must account for what happens when resources run low. The best system is the one that works on the worst hardware.
This covers:
- Resource efficiency & memory management
- Lazy loading & streaming
- Batch processing
- Caching
- Back-pressure
- Rate limiting (resource protection)
- Horizontal vs vertical scaling
- Cost optimization
The instinct question: “What happens when there’s 100x the load, or half the resources?”
If the answer is “it crashes or costs a fortune,” you have a Sustain problem.
Instinct #6: ORGANIZE
Section titled “Instinct #6: ORGANIZE”The problem: A chinchilla stashes seeds, bark, and dried plants all in the same burrow. Come winter, it digs through everything looking for seeds and gets a mouthful of bark shavings. It can’t find anything efficiently.
The principle: Data has structure. That structure should be intentional, consistent, and optimized for how the data will be used. Where data lives, how it’s named, how it’s organized: this determines how fast you can find it, how easy it is to maintain, and how painful it is to migrate.
This covers:
- Schema design
- Data modeling
- File & directory organization
- Normalization vs denormalization
- Data lake vs data warehouse
- Naming conventions
- Migration strategies
The instinct question: “Can someone unfamiliar with this system find and understand the data in 5 minutes?”
If not, you have an Organize problem.
The Six Instincts Together
Section titled “The Six Instincts Together”Every system design decision you ever make falls into one of these buckets:
| Instinct | Core Question | When Violated |
|---|---|---|
| Remember | What if it crashes? | Data loss, lost sessions, incomplete operations |
| Agree | Does everyone see the same truth? | Conflicts, duplication, silent corruption |
| Survive | What if something breaks? | Outages, cascading failures, lost revenue |
| Protect | Who can access this? | Breaches, leaks, compliance violations |
| Sustain | What if load increases 100x? | Slowdowns, OOM crashes, infrastructure bills |
| Organize | Can someone else understand this? | Tech debt, slow queries, migration nightmares |
When two instincts conflict, trade wisely:
- Remember vs Sustain: Storing everything forever costs money
- Agree vs Survive: Perfect consistency can kill availability (CAP theorem)
- Protect vs Sustain: Encryption adds latency
- Survive vs Organize: Redundancy means duplicate data in multiple places
There are no perfect systems. Only intentional tradeoffs.