I Teach You AI Engineering & System Design • 0.5M+ Audience
Join 250K+ Subscribers →
Joined April 2023
- Tweets20.7K
- Following135
- Followers57.4K
- Likes24.9K
Pinned Tweet
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 retweeted
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 retweeted
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!
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!
👋 PS - Want my AI Engineering Playbook for FREE?
Join my newsletter with 250K+ software engineers right now:
newsletter.systemdesign.one/…
👋 PS - Want my AI Engineering Playbook for FREE?
Join my newsletter with 250K+ software engineers right now:
newsletter.systemdesign.one/…
I got 3 hours back per week while building my tiny AI agent.
(And I did it by hiring an AI employee.)
Everyone thinks building an AI agent is about choosing the right model.
Writing better prompts and/or connecting more tools.
No.
Building an AI agent requires planning, testing & tracking progress.
And what I love about this is... you don't need a large engineering team to get started.
You see, I'm building a tiny AI agent from scratch.
And documenting every step in a newsletter so others can build along.
But before I can explain how AI agents work, I need to build one myself.
Most people underestimate this part.
They focus on writing code without tracking decisions.
Add features without documenting why.
Start writing tutorials before testing the implementation.
And they wonder why their projects become difficult to manage.
So I hired an AI Engineering Project Coordinator.
His name is Viktor, and he's my new AI employee.
I gave him 3 responsibilities:
1. Track the development.
↳ Keep a record of tasks, milestones & blockers as I build the agent.
2. Coordinate the documentation.
↳ Track architecture decisions, implementation progress & topics I need to explain in the newsletter.
3. Keep the project moving.
↳ Follow up on unfinished work, prepare progress updates & flag decisions that need my attention.
I still design architecture, write code & review results.
Viktor coordinates the work around them.
In 7 days, Viktor coordinated 8 engineering tasks across development, documentation & newsletter preparation.
i,e., I got 3 hours back to focus on building the agent.
I used to think building a small project meant handling every part of it myself.
Now I spend more time building the agent & teaching others how it works.
I think more software engineers will start working this way.
If you're building software, hire @viktor_com for your team. Start free, no credit card.
#AIemployee #SoftwareEngineering
Paid Partnership
🤝 Paid partnership
The most impressive part of AI is seeing a simple idea turn into a real business on Capafy, an AI Skill marketplace.
You built it. You launched it. You posted videos. You attracted customers. You made your first sales. Now what?
One creator built CloneCut, a Claude skill that helps people recreate viral video formats using their own photos & ideas.
They promoted it through Instagram & TikTok, attracted paying customers, and saw some return for more.
Now the creator reports over $289K in sales on Capafy in just 30 days.
You don’t need to build a massive AI product to start a business. Sometimes a simple tool that solves a specific problem is enough to get started.
🤝 Paid partnership
Over $289K in sales on Capafy in just 30 days! Congrats to CloneCut!
It is exciting to see Agent Skills meeting real user needs and generating revenue for creators.
Looking forward to more milestones ahead!
How to start a software engineering podcast (in 2026)?
- Record 30 minutes to 2 hours of audio
- Stop re-recording every podcast episode from scratch
- Create a Professional Voice Clone with HeyGen
- Use the HeyGen API to add your voice to apps & workflows
Just get in the habit of creating podcast episodes (with your own voice, of course) and spend less time recording the same things over & over.
🤝 Paid partnership
If you want to become top-tier with AI coding agents, then learn these 10 testing techniques (save now):
1. Test oracle: The rule that says pass or fail. If one agent writes the code and the rule, it can make the same mistake in both. Then the test passes on wrong code. Write the rule yourself, or get a second check.
2. End-to-end test: An agent opens your app in a real browser. It clicks & types like a person. Then it checks the screen. These tests are slow, so keep very few for the key flows.
3. Mocks vs integration: A mock is a fake stand-in for a real service. It shows your code asked the right thing. It can't show what the real service will answer. An integration test talks to the real service, or a close copy. Use both.
4. Preview environment: Each pull request gets its own live copy of the app. You click around & run tests there before the code joins the main app.
5. Unhappy paths: The happy path is when all goes well. Unhappy paths are the rest: bad input, a page with no data, a user trying to see someone else's stuff. Test these on purpose. Bugs hide where no one looks.
6. Regression: Something that worked, then broke after a change. Keep your old tests & run them again. When you fix a bug, add a test for it so it can't sneak back.
7. Flaky test: Same code. Sometimes it passes. Sometimes it fails. Timing, shared data, and the network are common causes. Fix it. If you can't yet, set it aside and track it.
8. Test isolation: Each test makes its own data & cleans up after. One test should never need another to run first. If tests share data, a change in run order can break them.
9. Test evidence: Save screenshots, videos, or traces of each run. Good tools record a trace or replay you can step through. When a test fails, you see what it saw.
10. Spec-driven testing: Write down what the feature should do. Then write tests from that list. Tests written by reading the code copy the code's bugs.
👋 PS - TestSprite handles the end-to-end side for you: point it at a PR preview, and it writes tests from your spec, runs them in a real browser, and keeps a replay of every run.
testsprite.com/?via=neokim-x
What should a research agent do when retrieval finds no answer?
1 Identify the missing evidence
2 Find people who can provide it
3 Run the research
4 Connect the findings to what is known
Qualitate turns an empty search result into a research task.
🤝 Paid partnership
We just raised $25M from Insight Partners to replace Gartner, McKinsey, and GLG.
RIP the Quadrant, the 80-page consulting deck, and the $2000 expert network call.
Our revenue run-rate is up 10x+ this year.
100+ investment firms and enterprises use Qualitate to inform decisions with firsthand evidence.
Here's how:
qualitate.io/book-a-demo
Imagine you're building an AI research agent:
Agent starts a document processing task that takes several minutes.
Without webhooks, your app needs to repeatedly poll processing service to check if task finished.
With webhooks, service sends an event when processing finishes.
Backend receives the event, verifies it & resumes agent's workflow.
(This pattern applies to customer support agents, coding agents & async AI workflows.)
👋 PS - Agents can’t react to your product if all it offers is polling.
If your customers (or their agents) want webhooks from your API, you own the hard part: retries, signing, per-customer endpoints, delivery logs.
Svix runs that for you, so you ship webhooks in days, not quarters.
link.svix.com/the-syst-01
