Architectural Drivers

What Drivers Are

Architectural drivers are the inputs that make one design correct and its alternatives wrong. Two systems with identical features but different drivers deserve different architectures. Designing without naming drivers produces generic diagrams — the architectural equivalent of a solution looking for a problem.

                    ┌─────────────────────┐
   DOMAIN ─────────►│                     │
   SCALE     ──────►│    ARCHITECTURE     │
   QUALITY NFRs ───►│     DECISIONS       │
   CONSTRAINTS ────►│                     │
   ENVIRONMENT ────►│                     │
                    └─────────────────────┘
   change a driver → different architecture is now CORRECT

The Five Driver Categories

1. Domain — what the business fundamentally does.

Domain	Dominant design concern
Payments/ledger	Correctness, auditability, exactly-once
Social feed	Read fan-out, eventual consistency tolerance
Ride matching	Real-time geospatial, sub-second decisions
Video platform	Storage economics, transcoding pipeline, CDN

Domain dictates vocabulary and invariants; ignoring it yields technically clever, business-wrong designs.

2. Scale — how much traffic/data, now and growing.

10k users: anything works. 10M DAU read-heavy: caching + replicas dominate. 1M writes/sec: sharding and write-path redesign dominate. Scale numbers are not decoration — they select the entire strategy.

3. Quality attributes — ranked -ilities from the previous lesson (latency, availability, consistency…). These convert vague goodness into testable targets.

4. Constraints — the walls: budget ceiling, deadline, team skills, mandated tech, compliance regimes. A brilliant Cassandra choice fails if no one can operate it.

5. Environment — where the system lives: cloud vs on-prem, existing services to integrate, organizational team boundaries (Conway’s law — your org chart becomes your call graph whether you plan it or not).

Drivers in Action: Same Feature, Different Architectures

Feature: user avatars.

 STARTUP (100k users)              GLOBAL PLATFORM (500M users)
 drivers: cost, simplicity         drivers: scale, latency, durability

 Client → App → S3                 Client → CDN edge → regional origin
          (direct presigned PUT)        → S3 cross-region replication
 
 one bucket, lifecycle rules       multipart upload, dedup pipeline,
 done. correct for driver set.     abuse scanning, per-region residency.
                                   correct for ITS driver set.

Neither is over- or under-engineered — each matches its drivers. Copying the platform’s answer into the startup burns budget on problems that do not exist there yet.

Ranking Drivers Explicitly

Before drawing boxes, write the top three drivers in order:

 EXAMPLE — ride-share backend:
 1. Real-time location writes (~50k/s peak)      ← dominates storage choice
 2. Sub-second match latency                     ← dominates geo-index + cache
 3. Small team, managed-services bias            ← eliminates self-operated exotic tech

Every later decision should trace back to a named driver. Decisions with no driving requirement are complexity smuggled aboard.

Interview Framing

The first five minutes of a design interview are driver extraction: scale, latency expectations, consistency needs, constraints (“assume small team” changes answers). Candidates who skip this draw generic architectures; candidates who surface drivers get designs that are right for the stated problem — which is the thing being graded.