Neo Kim

I Teach You AI Engineering & System Design • 0.5M+ Audience

[Neo Kim @systemdesignone]

If I had 6 months to master System Design.

I’d do this.

STAGE 1: Foundations

- Learn: Scalability, Availability & Reliability; Latency vs Throughput; CAP/PACELC & Tradeoffs; Back of the Envelope Estimation; Requirements (Functional vs NFR).

- Practice: Run capacity estimates & map functional vs non-functional requirements with explicit tradeoffs for one real system.

- Why: Everything else is built on these numbers & constraints. You decide the acceptable limits before any design starts.

===

STAGE 2: Networking & APIs

- Learn: DNS, TCP/UDP, HTTP/TLS; REST, GraphQL & gRPC; API Gateway; WebSockets/SSE/Long Polling; AuthN/AuthZ (JWT, OAuth, Sessions).

- Practice: Design one feature with two API styles, add an API gateway & secure it with proper auth flows.

- Why: Clients and services only talk through contracts. Wrong choices here create permanent coupling and security holes.

===

STAGE 3: Traffic & Delivery

- Learn: Load Balancing (L4 vs L7); Reverse Proxy; CDN & Edge; Rate Limiting; Consistent Hashing.

- Practice: Route traffic for a service under load, add edge caching, and enforce rate limits with consistent hashing.

- Why: Traffic is unpredictable. These controls keep the system responsive & fair under real-world spikes.

===

STAGE 4: Databases & Storage

- Learn: SQL vs NoSQL; Data Modeling & Indexing; Replication; Sharding/Partitioning; Transactions & Isolation; Object/Blob Storage.

- Practice: Model data for mixed workloads, choose replication and sharding strategy, and set isolation levels that match consistency needs.

- Why: Data is the source of truth. Ownership, consistency & access patterns determine whether the system stays correct as it grows.

===

STAGE 5: Caching

- Learn: Cache Placement (Client, CDN, App, DB); Strategies (Aside, Through, Around, Write-Back); Eviction & TTLs; Invalidation; Redis/Memcached Patterns.

- Practice: Add multi-layer caching to a hot path and define invalidation rules that prevent stale or inconsistent reads.

- Why: Latency budgets are tight. Caching multiplies capacity only when placement and invalidation are deliberate.

===

STAGE 6: Distributed Systems

- Learn: Consistency Models; Quorum & Leader Election; Consensus (Raft / Paxos intuition); Distributed Transactions (2PC, Sagas); Idempotency, Retries & Dedup.

- Practice: Simulate partitions & partial failures, then show safe retries and a chosen consistency model under those conditions.

- Why: Networks fail & nodes diverge. You design the failure behavior that generated or concurrent code will ignore.

===

STAGE 7: Messaging & Async

- Learn: Queues vs Pub/Sub; Delivery Semantics (At-most/At-least/Exactly-once); Kafka/Event Streams; Backpressure & Dead Letters; Event-Driven Architecture.

- Practice: Build one flow with queues & one with events, measure delivery guarantees, and add backpressure handling.

- Why: Synchronous calls do not scale forever. Async boundaries absorb load spikes & decouple teams and services.

===

STAGE 8: Architecture Patterns

- Learn: Monolith vs Microservices; Service Discovery; Circuit Breaker, Timeout, Bulkhead; CQRS & Event Sourcing; Multi-Region/Active-Active.

- Practice: Implement one feature in two styles and compare operational cost, failure isolation, and change speed.

- Why: No pattern is free. You pick the style that matches team size, change rate, and failure tolerance.

===

STAGE 9: Reliability & Production

- Learn: Observability (Logs, Metrics, Traces); SLIs/SLOs/Error Budgets; Failure Modes & Graceful Degradation; CI/CD, Rollouts & Rollbacks; Security, Secrets & Least Privilege.

- Practice: Instrument a service with full traces, define SLOs and error budgets, and run a controlled rollout with rollback.

- Why: Systems run continuously. Observability & controlled change keep production stable while features keep shipping.

===

STAGE 10: Classic Designs

- Learn: URL Shortener; Rate Limiter; Chat/Messaging; News Feed; Notifications; File Storage (Dropbox); Video Streaming; Search/Web Crawler; Ride Hailing/Payments.

- Practice: Design two classic systems end-to-end (requirements, high-level design, deep dives, trade-offs) & write the key decisions.

- Why: Patterns become judgment only when you apply them to real constraints and explain the choices clearly.

Learn to design systems that scale, fail safely, & ship.

Bookmark & RT!

[Neo Kim @systemdesignone]

@e_opore arch is the peak

[Neo Kim @systemdesignone]

@CodeByPoonam smart except using a macbook

[Neo Kim @systemdesignone]

@petarivanovv9 found some new ones here.

[Neo Kim @systemdesignone]

👋 PS - Want my AI Engineering Playbook for FREE?

Join my newsletter with 250K+ software engineers right now:

https://t.co/E3iXTK2W4q

[Neo Kim @systemdesignone]

If I had 6 months to master System Design.

I’d do this.

STAGE 1: Foundations

- Learn: Scalability, Availability & Reliability; Latency vs Throughput; CAP/PACELC & Tradeoffs; Back of the Envelope Estimation; Requirements (Functional vs NFR).

- Practice: Run capacity estimates & map functional vs non-functional requirements with explicit tradeoffs for one real system.

- Why: Everything else is built on these numbers & constraints. You decide the acceptable limits before any design starts.

===

STAGE 2: Networking & APIs

- Learn: DNS, TCP/UDP, HTTP/TLS; REST, GraphQL & gRPC; API Gateway; WebSockets/SSE/Long Polling; AuthN/AuthZ (JWT, OAuth, Sessions).

- Practice: Design one feature with two API styles, add an API gateway & secure it with proper auth flows.

- Why: Clients and services only talk through contracts. Wrong choices here create permanent coupling and security holes.

===

STAGE 3: Traffic & Delivery

- Learn: Load Balancing (L4 vs L7); Reverse Proxy; CDN & Edge; Rate Limiting; Consistent Hashing.

- Practice: Route traffic for a service under load, add edge caching, and enforce rate limits with consistent hashing.

- Why: Traffic is unpredictable. These controls keep the system responsive & fair under real-world spikes.

===

STAGE 4: Databases & Storage

- Learn: SQL vs NoSQL; Data Modeling & Indexing; Replication; Sharding/Partitioning; Transactions & Isolation; Object/Blob Storage.

- Practice: Model data for mixed workloads, choose replication and sharding strategy, and set isolation levels that match consistency needs.

- Why: Data is the source of truth. Ownership, consistency & access patterns determine whether the system stays correct as it grows.

===

STAGE 5: Caching

- Learn: Cache Placement (Client, CDN, App, DB); Strategies (Aside, Through, Around, Write-Back); Eviction & TTLs; Invalidation; Redis/Memcached Patterns.

- Practice: Add multi-layer caching to a hot path and define invalidation rules that prevent stale or inconsistent reads.

- Why: Latency budgets are tight. Caching multiplies capacity only when placement and invalidation are deliberate.

===

STAGE 6: Distributed Systems

- Learn: Consistency Models; Quorum & Leader Election; Consensus (Raft / Paxos intuition); Distributed Transactions (2PC, Sagas); Idempotency, Retries & Dedup.

- Practice: Simulate partitions & partial failures, then show safe retries and a chosen consistency model under those conditions.

- Why: Networks fail & nodes diverge. You design the failure behavior that generated or concurrent code will ignore.

===

STAGE 7: Messaging & Async

- Learn: Queues vs Pub/Sub; Delivery Semantics (At-most/At-least/Exactly-once); Kafka/Event Streams; Backpressure & Dead Letters; Event-Driven Architecture.

- Practice: Build one flow with queues & one with events, measure delivery guarantees, and add backpressure handling.

- Why: Synchronous calls do not scale forever. Async boundaries absorb load spikes & decouple teams and services.

===

STAGE 8: Architecture Patterns

- Learn: Monolith vs Microservices; Service Discovery; Circuit Breaker, Timeout, Bulkhead; CQRS & Event Sourcing; Multi-Region/Active-Active.

- Practice: Implement one feature in two styles and compare operational cost, failure isolation, and change speed.

- Why: No pattern is free. You pick the style that matches team size, change rate, and failure tolerance.

===

STAGE 9: Reliability & Production

- Learn: Observability (Logs, Metrics, Traces); SLIs/SLOs/Error Budgets; Failure Modes & Graceful Degradation; CI/CD, Rollouts & Rollbacks; Security, Secrets & Least Privilege.

- Practice: Instrument a service with full traces, define SLOs and error budgets, and run a controlled rollout with rollback.

- Why: Systems run continuously. Observability & controlled change keep production stable while features keep shipping.

===

STAGE 10: Classic Designs

- Learn: URL Shortener; Rate Limiter; Chat/Messaging; News Feed; Notifications; File Storage (Dropbox); Video Streaming; Search/Web Crawler; Ride Hailing/Payments.

- Practice: Design two classic systems end-to-end (requirements, high-level design, deep dives, trade-offs) & write the key decisions.

- Why: Patterns become judgment only when you apply them to real constraints and explain the choices clearly.

Learn to design systems that scale, fail safely, & ship.

Bookmark & RT!

[Neo Kim @systemdesignone]

One of my favorite quotes:

"Truth can only be found in one place: the code" - Robert C Martin

[Neo Kim @systemdesignone]

If I had 6 months to master System Design.

I’d do this.

STAGE 1: Foundations

- Learn: Scalability, Availability & Reliability; Latency vs Throughput; CAP/PACELC & Tradeoffs; Back of the Envelope Estimation; Requirements (Functional vs NFR).

- Practice: Run capacity estimates & map functional vs non-functional requirements with explicit tradeoffs for one real system.

- Why: Everything else is built on these numbers & constraints. You decide the acceptable limits before any design starts.

===

STAGE 2: Networking & APIs

- Learn: DNS, TCP/UDP, HTTP/TLS; REST, GraphQL & gRPC; API Gateway; WebSockets/SSE/Long Polling; AuthN/AuthZ (JWT, OAuth, Sessions).

- Practice: Design one feature with two API styles, add an API gateway & secure it with proper auth flows.

- Why: Clients and services only talk through contracts. Wrong choices here create permanent coupling and security holes.

===

STAGE 3: Traffic & Delivery

- Learn: Load Balancing (L4 vs L7); Reverse Proxy; CDN & Edge; Rate Limiting; Consistent Hashing.

- Practice: Route traffic for a service under load, add edge caching, and enforce rate limits with consistent hashing.

- Why: Traffic is unpredictable. These controls keep the system responsive & fair under real-world spikes.

===

STAGE 4: Databases & Storage

- Learn: SQL vs NoSQL; Data Modeling & Indexing; Replication; Sharding/Partitioning; Transactions & Isolation; Object/Blob Storage.

- Practice: Model data for mixed workloads, choose replication and sharding strategy, and set isolation levels that match consistency needs.

- Why: Data is the source of truth. Ownership, consistency & access patterns determine whether the system stays correct as it grows.

===

STAGE 5: Caching

- Learn: Cache Placement (Client, CDN, App, DB); Strategies (Aside, Through, Around, Write-Back); Eviction & TTLs; Invalidation; Redis/Memcached Patterns.

- Practice: Add multi-layer caching to a hot path and define invalidation rules that prevent stale or inconsistent reads.

- Why: Latency budgets are tight. Caching multiplies capacity only when placement and invalidation are deliberate.

===

STAGE 6: Distributed Systems

- Learn: Consistency Models; Quorum & Leader Election; Consensus (Raft / Paxos intuition); Distributed Transactions (2PC, Sagas); Idempotency, Retries & Dedup.

- Practice: Simulate partitions & partial failures, then show safe retries and a chosen consistency model under those conditions.

- Why: Networks fail & nodes diverge. You design the failure behavior that generated or concurrent code will ignore.

===

STAGE 7: Messaging & Async

- Learn: Queues vs Pub/Sub; Delivery Semantics (At-most/At-least/Exactly-once); Kafka/Event Streams; Backpressure & Dead Letters; Event-Driven Architecture.

- Practice: Build one flow with queues & one with events, measure delivery guarantees, and add backpressure handling.

- Why: Synchronous calls do not scale forever. Async boundaries absorb load spikes & decouple teams and services.

===

STAGE 8: Architecture Patterns

- Learn: Monolith vs Microservices; Service Discovery; Circuit Breaker, Timeout, Bulkhead; CQRS & Event Sourcing; Multi-Region/Active-Active.

- Practice: Implement one feature in two styles and compare operational cost, failure isolation, and change speed.

- Why: No pattern is free. You pick the style that matches team size, change rate, and failure tolerance.

===

STAGE 9: Reliability & Production

- Learn: Observability (Logs, Metrics, Traces); SLIs/SLOs/Error Budgets; Failure Modes & Graceful Degradation; CI/CD, Rollouts & Rollbacks; Security, Secrets & Least Privilege.

- Practice: Instrument a service with full traces, define SLOs and error budgets, and run a controlled rollout with rollback.

- Why: Systems run continuously. Observability & controlled change keep production stable while features keep shipping.

===

STAGE 10: Classic Designs

- Learn: URL Shortener; Rate Limiter; Chat/Messaging; News Feed; Notifications; File Storage (Dropbox); Video Streaming; Search/Web Crawler; Ride Hailing/Payments.

- Practice: Design two classic systems end-to-end (requirements, high-level design, deep dives, trade-offs) & write the key decisions.

- Why: Patterns become judgment only when you apply them to real constraints and explain the choices clearly.

Learn to design systems that scale, fail safely, & ship.

Bookmark & RT!

[Neo Kim @systemdesignone]

One of my favorite quotes:

"Truth can only be found in one place: the code" - Robert C Martin

[Neo Kim @systemdesignone]

@socialwithaayan haven't tried ideogram in a while...nice update

[Neo Kim @systemdesignone]

@sevalla_hosting yep, follow 80/20

[Neo Kim @systemdesignone]

@e_opore Tks

[Neo Kim @systemdesignone]

@RaulJuncoV 🔥

[Neo Kim @systemdesignone]

@csaba_kissi 🤔

[Neo Kim @systemdesignone]

@swapnakpanda ah, nice list!

[Neo Kim @systemdesignone]

@csaba_kissi amazing!

[Neo Kim @systemdesignone]

@svpino why do we work longer after AI than before...

[Neo Kim @systemdesignone]

@RaulJuncoV right on my weekend list

[Neo Kim @systemdesignone]

@techyoutbe nice one!

[Neo Kim @systemdesignone]

@examaddaorg Tks

[Neo Kim @systemdesignone]

If I had 6 months to become a Software Architect in the AI era.

I’d do this.

STAGE 1: Foundations & Role

- Learn: What architecture is, Architect vs Senior vs Tech Lead, quality attributes, functional vs non-functional requirements, stakeholders & constraints.

- Practice: Map quality attributes & conflicting drivers for one real system.

- Why: AI writes code. Architects decide what must not change when stakeholders and constraints shift.

STAGE 2: Architectural Thinking

- Learn: Tradeoffs, ADRs, fitness functions, technical debt, Conway’s Law.

- Practice: Write 5 ADRs & define fitness functions that reject bad designs.

- Why: AI proposes options. You own the recorded decision & its long-term cost.

STAGE 3: Design Principles

- Learn: SOLID, cohesion/coupling, boundaries, dependency inversion, YAGNI/KISS, complexity budget.

- Practice: Refactor a coupled service into ports & adapters under a hard complexity limit.

- Why: Generated code grows fast. Principles keep boundaries intact so change stays local.

STAGE 4: Styles & Patterns

- Learn: Modular monolith, microservices, hexagonal/clean, event-driven, CQRS & event sourcing.

- Practice: Implement one feature three ways & measure operational differences.

- Why: No single style wins. You choose & evolve the pattern that matches team size and change rate.

STAGE 5: Domain Modeling

- Learn: Strategic DDD, bounded contexts, aggregates, ubiquitous language, anti-corruption layer.

- Practice: Model a domain with two teams + one AI agent and add an anti-corruption boundary.

- Why: AI multiplies features. Clear contexts stop the domain from becoming inconsistent.

STAGE 6: Data & Persistence

- Learn: Data ownership, SQL vs NoSQL, partitioning, sagas/outbox, polyglot persistence.

- Practice: Design ownership boundaries + outbox for a system that mixes relational and vector data.

- Why: Agents write data. Ownership and consistency rules prevent silent corruption.

STAGE 7: Distributed Systems

- Learn: CAP/PACELC, consistency models, failure modes, idempotency, fallacies of distribution.

- Practice: Simulate partitions and show safe retries with an explicit consistency choice.

- Why: AI calls are multi-hop and async. You design for the failures generated code ignores.

STAGE 8: Integration & APIs

- Learn: Sync vs async, contracts & versioning, choreography vs orchestration, gateways.

- Practice: Build a versioned contract plus hybrid sync/async flow that includes agent steps.

- Why: Agents call constantly. Stable contracts and the right orchestration keep the system evolvable.

STAGE 9: Evolution & Production

- Learn: Evolutionary architecture, observability, SLIs/SLOs, resilience patterns, least privilege.

- Practice: Strangle one module, add full traces including agent calls & set error budgets.

- Why: Systems change while agents run. You keep production stable under continuous autonomous activity.

STAGE 10: Practice & Communication

- Learn: C4 diagrams, ADRs, architecture katas, classic system cases.

- Practice: Produce a full C4 + ADR set and publish one bottleneck teardown.

- Why: Architects are hired for judgment and clear decisions that survive teams, scale, and AI-driven change.

CRUD is dead. AI writes the boilerplate.

The "modern architect" builds the decision system that stays coherent under change, teams & autonomous agents.

Bookmark & RT!

[Neo Kim @systemdesignone]

👋 PS - Want my AI Engineering Playbook for FREE?

Join my newsletter with 250K+ software engineers right now:

https://t.co/E3iXTK2W4q