System Design vs Coding

The Core Shift

Coding asks: does this logic produce correct output for this input? System design asks: do these cooperating parts deliver the right behavior under load, partial failure, and cost pressure? The unit of work changes from functions and classes to services, datastores, and networks — and with it, everything about what “correct” means.

 CODING MINDSET                     SYSTEM DESIGN MINDSET

 unit: function / class             unit: service / datastore / network link
 verified by: unit tests            verified by: load tests, chaos drills,
                                    production metrics
 failure = exception                failure = timeout, partition, slow
 (deterministic)                    neighbor, poisoned message
 state: in memory, dies with        state: durable, replicated,
 process                            eventually consistent
 latency: nanoseconds–µs            latency: ms–seconds, highly variable
 "works on my machine" is           every machine is different;
 meaningful                         locality is the whole game

Why Strong Coders Struggle at First

The reflexes that make excellent coders actively mislead in system design:

Coding instinct	Where it breaks
Make it correct, then fast	At scale, availability and latency ARE correctness features
DRY everywhere	Copying a small service boundary beats sharing a fragile one
Single source of truth in one place	That place becomes a SPOF and write bottleneck
Minimize moving parts locally	Distributed systems REQUIRE multiple moving parts; skill is managing them
Deterministic thinking	Networks drop, clocks skew, retries duplicate — nondeterminism is ambient

The strongest coder-to-architect transition is internalizing that partial failure is normal, not exceptional.

A Concrete Contrast

Task: store user sessions.

 CODER'S ANSWER                   ARCHITECT'S ANSWER
 HashMap<sessionId, Session>      Redis cluster, TTL-based expiry,
 in app process memory            replica per AZ, session data kept
                                  minimal + reconstructable because:
 - O(1) access ✓                  - app servers scale horizontally →
 - simple ✓                         shared external store required
                                  - node death must not log out an
                                    entire region's users
                                  - eviction policy replaces manual cleanup

Both are “correct.” Only one survives contact with two app servers.

What Transfers Directly

System design is not alien to coding — several instincts remain assets:

• Complexity aversion: the best architecture is usually the fewest boxes that meet requirements.
• Interface discipline: contracts between services deserve the same rigor as API signatures.
• Invariant reasoning: knowing which data must never diverge drives consistency choices.
• Debugging mindset: tracing a request across services is stack-tracing at network scale.

Interview Framing

When asked to design a system, candidates who jump straight to drawing boxes without stating assumptions are coding on a whiteboard. The architectural habit to demonstrate: state the workload, name the dominant constraint (reads? writes? geo? consistency?), then let those facts pick the components.