Order of Magnitude
An order of magnitude is a factor of ten. When you move from 10,000, you have gone up one order of magnitude. From 1,000,000 is three orders of magnitude. This way of thinking — in powers of 10 — helps you quickly assess scale, compare options, and recognize when a change is big enough to matter.
The Everyday Version
Money Decisions
Not all financial decisions deserve the same attention.
$1 decision:
- Which brand of salt to buy
- Spend 5 seconds thinking about it
$10 decision:
- Which restaurant for lunch
- Spend a few minutes
$100 decision:
- Which pair of shoes to buy
- Compare a few options, maybe sleep on it
$1,000 decision:
- Which laptop to buy
- Research for a day or two
$10,000 decision:
- Which car to buy (or whether to buy one at all)
- Research for weeks, test drive several options
$100,000 decision:
- Which house to buy, which city to move to
- Research for months, consult experts
Each jump of 10x deserves roughly 10x more thought.
Spending an hour choosing salt is absurd.
Spending 5 seconds choosing a house is reckless.
Time at Different Scales
1 second: Blinking, clicking a button
10 seconds: Tying your shoes, sending a text
100 seconds: Making a cup of coffee
1,000 seconds (17 min): A short meeting, a shower
10,000 seconds (2.8 hr): A movie, a long meeting
100,000 seconds (28 hr): Slightly more than a full day
Each step up changes your planning:
- 1-second tasks: No planning needed
- 10-second tasks: Still trivial
- 100-second tasks: Worth batching with similar tasks
- 1,000-second tasks: Need to be scheduled
- 10,000-second tasks: Major time commitments
- 100,000-second tasks: Multi-day events
Distance and Travel
1 km: A 10-minute walk
10 km: A bike ride, a short drive
100 km: A day trip by car
1,000 km: A domestic flight
10,000 km: An international flight
Each order of magnitude changes the mode of transport:
- Walking works for 1 km
- A car works for 10-100 km
- A plane works for 1,000-10,000 km
Trying to walk 100 km or fly 1 km are both absurd.
The right tool depends on the order of magnitude.
Audience Size
10 people: A dinner party. You know everyone's name.
100 people: A wedding. You recognize most faces.
1,000 people: A school. You know some by name.
10,000 people: A small town. You know almost nobody.
100,000 people: A stadium. You are a face in the crowd.
1,000,000 people: A city. Individual identity disappears.
Each jump changes how you communicate:
- 10: Personal conversation
- 100: A speech
- 1,000: A newsletter
- 10,000: Mass media
- 1,000,000: A platform with algorithms
Why Orders of Magnitude Matter
The human brain is not wired for large numbers.
We intuitively feel the difference between 1 and 10.
We struggle with the difference between 1 million
and 1 billion.
Let's make it concrete:
- 1 million seconds = 11.6 days
- 1 billion seconds = 31.7 years
That is the difference between "less than two weeks"
and "an entire career." Same words (million, billion),
wildly different meaning.
When someone says a government spent $1 billion
instead of $1 million, they did not spend "a bit more."
They spent 1,000 times more. Three orders of magnitude.
Connecting to Technology
Latency: Where Every 10x Matters
In computing, the speed of operations spans many orders of magnitude. Each level demands different design decisions.
Operation Time
-----------------------------------------
CPU register access 0.3 ns
L1 cache access 1 ns
L2 cache access 4 ns
RAM access 100 ns
SSD read 100,000 ns (0.1 ms)
HDD read 10,000,000 ns (10 ms)
Network round trip (same city) 1,000,000 ns (1 ms)
Network round trip (cross-country) 50,000,000 ns (50 ms)
Network round trip (intercontinental) 150,000,000 ns (150 ms)
From CPU register to intercontinental network:
9 orders of magnitude. 0.3 nanoseconds to 150 milliseconds.
What this means for design:
1 ms response time:
- Everything must be in memory
- No disk access, no network calls
- Used for: high-frequency trading, game engines
100 ms response time:
- Can hit a database or make one network call
- Feels instant to users
- Used for: web page loads, API responses
1 second response time:
- Can do moderate computation or several network calls
- Users notice but will wait
- Used for: complex searches, report generation
10 seconds response time:
- Users get impatient, may abandon the task
- Need progress indicators
- Used for: file uploads, batch operations
100 seconds response time:
- Must run in the background with notifications
- Users will not stare at a loading screen for 2 minutes
- Used for: video processing, large exports
The right architecture depends entirely on which
order of magnitude your response time must be in.
Storage: MB vs GB vs TB
1 MB: A photo, a short document
1 GB: A movie, 1,000 photos (1,000x more)
1 TB: 1,000 movies, a million photos (1,000x more again)
1 PB: A million movies (1,000x more again)
What changes at each scale:
Megabytes (personal files):
- Fits on any device
- No special storage strategy needed
- Backup to a USB drive
Gigabytes (personal media library):
- Fits on a laptop or phone
- Might need to manage space
- Cloud backup is affordable
Terabytes (small company data):
- Needs dedicated storage
- Backup strategy becomes important
- Costs start to matter ($20-50/month for cloud)
Petabytes (large company data):
- Needs distributed storage across many machines
- Data cannot fit on any single device
- Specialized systems required (HDFS, S3, etc.)
- Costs: millions per year
Exabytes (global platforms — Google, Facebook):
- Custom-built storage infrastructure
- Entire data centers dedicated to storage
- Years of engineering to manage at this scale
Users: Each Magnitude Changes Architecture
10 users:
- A single laptop can serve everyone
- No need for a database (a file is fine)
- Deploy manually
- You can email each user personally
100 users:
- A single server handles this easily
- Basic database is helpful
- Simple deployment process
- An email list for communication
1,000 users:
- Still one server, but monitoring matters
- Need proper database with backups
- Automated deployment helps
- Support tickets start to arrive
10,000 users:
- Need load balancing (2-3 servers)
- Database performance tuning required
- Caching becomes important
- Need a support system, not just email
100,000 users:
- Need a proper ops team or managed infrastructure
- Database replication for reads
- CDN for static content
- Automated scaling
1,000,000 users:
- Distributed architecture required
- Multiple database instances, possibly sharded
- Global CDN, multiple regions
- Dedicated teams for infrastructure, security, support
10,000,000 users:
- Everything must be distributed and redundant
- Custom tooling for deployment and monitoring
- Edge computing for latency-sensitive features
- The infrastructure IS the product
Each 10x jump in users forces architectural decisions
you could ignore at the previous scale.
Cost at Scale
A common trap: calculating cost per unit at small scale
and assuming it holds.
Sending an email:
- Cost per email (at small scale): $0.001
- 1,000 emails per month: $1 (who cares?)
- 1,000,000 emails per month: $1,000 (budget item)
- 1,000,000,000 emails per month: $1,000,000 (major cost)
But also: at larger scales, bulk pricing kicks in.
- 1 billion emails might cost $0.0001 each = $100,000
- Still a large number, but 10x less than naive math
Orders of magnitude matter in both directions:
- Small costs become large costs at scale
- But unit economics can improve at scale too
Order of Magnitude as a Decision Tool
When comparing two options, ask:
"Is the difference an order of magnitude?"
If yes: The choice is obvious, do not overthink it
If no: Other factors (convenience, preference) dominate
Examples:
"Should I drive 5 minutes or 10 minutes to save $2?"
- Same order of magnitude for time (minutes)
- Same order of magnitude for money (single dollars)
- Choose based on convenience, not optimization
"Should I spend 1 hour or 1 week to save $10,000?"
- Different orders of magnitude for time
- Probably worth the week of effort
"Should I optimize this function that runs in 2ms or 3ms?"
- Same order of magnitude
- Probably not worth the effort
- Unless it runs millions of times per second
(then the aggregate is a different magnitude)
Common Pitfalls
- Treating all numbers as roughly the same. A million and a billion are not "both big numbers." They differ by 1,000x. That difference changes everything.
- Optimizing within the same order of magnitude. Going from 50ms to 30ms matters much less than going from 500ms to 50ms. Focus on the 10x improvements.
- Assuming linear scaling. A system that works for 1,000 users will not work for 1,000,000 users by just "adding more servers." Each order of magnitude often requires a different approach.
- Ignoring accumulation. A $0.001 cost per transaction seems trivial until you have a billion transactions. Always multiply small numbers by large ones to check.
- Over-engineering for the wrong scale. Building infrastructure for 10 million users when you have 100 is just as wasteful as building for 100 when you need to handle 10 million.
- Forgetting that magnitude affects quality, not just quantity. 10 support requests need personal replies. 10,000 need a knowledge base. 1,000,000 need AI-assisted responses. The approach changes, not just the volume.
Key Takeaways
- An order of magnitude is a factor of 10. Thinking in powers of 10 helps you assess scale and make proportionate decisions.
- Each order of magnitude often requires a fundamentally different approach — not just "more of the same."
- In technology, latency, storage, user count, and cost all behave differently at each order of magnitude.
- The difference between a million and a billion is not a rounding error — it is 1,000x, and it changes every decision.
- Use order of magnitude as a decision filter: if two options differ by less than 10x, the choice is about preference. If they differ by more than 10x, the choice is obvious.
- Match your effort to the magnitude of the decision. Small decisions deserve seconds. Large decisions deserve days.