Teach Yourself System Design by Email

Teaching yourself system design by email sounds like a gimmick until you notice what actually fails in self-study: you bookmark twelve essays, sketch nothing, and skip retrieval practice. A sequenced email series forces a cadence, a single objective per sitting, and a diagram you must confront on a phone screen where your usual excuses do not fit.

This is a personal learning series, not a team onboarding track and not a customer academy. You are the learner and the reviewer. That does not mean unsupervised generation. LLM hallucinations about “how Netflix does it” are how people fail interviews and production designs with equal confidence.

Cadensend is the self-hosted engine we use to turn one learning goal into a validated plan, grounded issues, and exactly-once delivery to your own verified address. MIT license. No hosted signup. Not ConvertKit. Not a bulk sender. GitHub.

Key Takeaways:

• Pick one design outcome per series (“I can design a URL shortener with ID generation and read path”), not “learn system design.”
• Ground issues in named sources: papers, RFCs, your own notes, a small set of classic posts — not “the model’s training data.”
• Every issue needs a sketch prompt. If you did not draw, you did not study.
• Use PNG diagrams in email and keep Mermaid/D2 in git. See SVG vs PNG.
• Review each issue the next morning before it can teach you a fake default.
• Measure with a blank-page redesign, not with whether you opened the mail.

Table of Contents:

• Why email beats a folder of tabs
• Choose a narrow design outcome
• Sources that are allowed to teach you
• Issue anatomy: claim, sketch, failure, citation
• A 12-issue spine you can actually finish
• Review so you do not memorize fiction
• Cadensend as a self-study scheduler
• From personal series to interview or production
• Frequently Asked Questions

Why email beats a folder of tabs

System design learning dies in two ways: binge and drift. Binge is a weekend of YouTube. Drift is “I’ll do consistent hashing later.” Email is a crude spaced scheduler. You will open it because it is already in the client you check.

Constraints help:

• Length. 800–1,200 words. You cannot hide from the sketch.
• One figure. If the figure needs a poster, the issue is two issues.
• A reply action. Email yourself the sketch photo or a 10-line write-up. That artifact is the study.

This is retrieval practice, which the learning literature has beaten to death for a reason — see the APA’s overview of retrieval practice. Email is just the delivery bus.

It is a bad bus for video-heavy courses and a good bus for diagrams plus constraints. If you wanted an interactive playground, use a notebook. If you wanted to remember the tradeoff table at 8:05am, use mail.

Compare internal onboarding email courses: those must match a company’s production. Your self-study series must match your sources. Do not mix “classic” load-balancer folklore with your employer’s odd topology unless you label the mix.

HinterBuild about is an engineering shop; we study this way because it survives incident weeks. Contact if you want the engine, not the syllabus. Implementation: backend API engineering.

Choose a narrow design outcome

Bad goals: “system design,” “FAANG interviews,” “distributed systems.”

Better:

• Design a URL shortener: ID space, redirects, analytics, abuse.
• Design a feed: fanout, pagination, idempotent writes.
• Design exactly-once email delivery (you will care if you use Cadensend).
• Design a rate limiter: algorithms, storage, failure modes.

Cadensend’s wizard wants topic, inclusions, exclusions, outcome, audience, cadence, timezone, tone. Fill exclusions: “no Kubernetes internals,” “no vendor bake-offs,” “no crypto.” Exclusions keep the planner from retrieving a GPU scheduling essay into a cache issue.

Audience is “me, staff engineer, rusty on queues” or “me, interviewing in six weeks.” Difficulty drift is the enemy. Review catches it; the brief prevents most of it.

Cadence: three issues a week maximum. Two is better. Pause during incidents. A scheduler that guilt-mails you is a product smell; Cadensend holds unapproved issues instead of spraying.

Sources that are allowed to teach you

Upload what you trust:

• Kleppmann’s Designing Data-Intensive Applications notes you typed yourself
• Papers you will actually cite (Dynamo, Raft — PDFs you keep)
• RFCs when you mean them (RFC 9110 for HTTP semantics, not vibes)
• A small set of architecture posts you have already read once
• Your own ADRs if this is prep for changing your system

Do not upload twenty random “system design cheat sheet” blogs. The model will average them into a diagram that never existed. That is hallucination with citations that look scholarly.

Cadensend cites chunks with deterministic links. If a claim has no span, you fail the issue in review. Keep the course updated when you add a paper; do not regenerate the whole spine.

For company-specific design, prefer team series with a reviewer. Self-study on internal topology still needs locks if anyone else might inherit the notes.

Issue anatomy: claim, sketch, failure, citation

Every issue should contain:

1. Objective in one sentence.
2. Claim — the tradeoff, not a history of Twitter.
3. Sketch prompt — “Draw client → LB → app → cache → DB. Mark what breaks if cache is down.”
4. One failure mode — thundering herd, split brain, clock skew, duplicate send.
5. Citation — to your source, not “industry best practices.”
6. Optional PNG — from a Mermaid spec, not from a model-drawn raster. Diagrams in email.

Subject lines should name the object: “ID generation for short URLs,” not “Let’s dive in.”

Plain-text part must include the sketch prompt. Image-blocked mail still teaches.

If you use AI to draft, regenerate sections, not the whole issue. HITL written courses still apply when the human is you. Wait overnight. Morning you is the reviewer.

A 12-issue spine you can actually finish

Here is a spine for “design a durable job + notify path” — close to how Cadensend sends mail, and useful beyond it. Adapt, do not worship.

1. What “exactly once” can mean (at-least-once + idempotency vs true once).
2. Outbox vs dual write. Cite your notes or our outbox post.
3. Queue claim: FOR UPDATE SKIP LOCKED. Pattern.
4. Retry, backoff, poison messages.
5. Idempotency keys. Guide.
6. Provider timeouts: write the intent record before the HTTP call.
7. Timezones and DST for “send at 9.”
8. Backpressure and rate limits.
9. Observability: what to log, what to redact.
10. Failure drill: worker dies after send, before ack.
11. Sketch the whole path from memory.
12. Change one constraint (multi-region) and redesign.

That is a curriculum, not a book report. Each issue maps to a source you ingested. Cadensend’s planner can vary the order; you still validate prerequisites.

Do not let the model insert a bonus GPU chapter. Exclusions exist so you can reduce LLM costs and stay on outcome.

Here is issue 6 (idempotency keys) written as the mail you would actually send yourself — compressed:

• Objective: You can name where the key is stored and what happens on retry after a provider 500.
• Claim: The send is not the source of truth; the row written before the HTTP call is.
• Sketch: Client → worker → delivery_attempts row → provider. Mark the crash window after HTTP success and before ack.
• Failure: Worker dies after the provider accepted mail. Without a key, you double-send. With a key, retry is a no-op.
• Citation: Your ingested notes plus, if you use our stack, the idempotency post.
• Action: Reply to the email with five lines: key fields, crash window, what the next retry reads.

If you cannot do the action with the mail closed the next morning, the issue was a blog post, not a lesson. Measure whether it taught that way, even in private.

For broader “10 million users” color, our system design for 10M users post is a sibling, not a substitute for your sketches.

Review so you do not memorize fiction

Use the 12-minute lesson review:

• Objective matches subject
• Every number and default has a span
• Sketch is doable on paper
• PNG/alt if present
• No fake Netflix internals

Hard-fail war stories in first person that you did not live. Models love “when we sharded.”

HITL approval gates: you do not auto-send. Cadensend awaits review.

Coding assistants help you extract a quote from a PDF. OpenClaw vs Claude Code is the daily-driver comparison. The ChatGPT cheat sheet is for prompts like “turn this Kleppmann paragraph into a sketch prompt; do not add facts.” Then you check the paragraph.

Cadensend as a self-study scheduler

Cadensend MVP is literally this audience: individual learner / creator, verified recipient, plan → ground → write → review → send once.

You pay for the LLM, the email provider, and the infra. The software is MIT. There is no hosted Cadensend account. You are not building a list. You are teaching yourself.

Use Plan Studio to lock issues you already learned so a regen cannot rewrite history while you are on issue 9. When you add a new paper, stale only the citing issues. Source-change maintenance.

Diagrams-as-data: Mermaid → SVG → PNG + required alt. You will thank this when you restudy in a year.

Run Center: generating, awaiting review, scheduled, sent, failed. Self-study still needs failed-job visibility. A silent skip is how spines die.

Product: Cadensend. Clone: github.com/HinterBuild/cadensend.

Figure 1. Inspect retrieved context, regenerate one section, diff, then approve — even when the learner is you.

If you later share the series with a study group, re-review as a team series. If you later send it to users, it is customer education and a different legal surface.

From personal series to interview or production

Interview. Practice issue 11 as a 45-minute blank page. Record yourself. The email series is prep, not a script. Interviewers punish memorized vendor diagrams.

Production. If the spine was “exactly-once notify,” implement it. Teaching without a repo is tourism. HinterBuild builds this class of system under backend API engineering and AI agents with send still gated.

Measurement. Did the course teach? You can redesign the path with the email closed. You can name two failure modes. You shipped a worker. Opens are irrelevant.

Pause the series rather than stacking three unread issues. Unread teaching is a notification tax.

Frequently Asked Questions

Can I really learn system design from email?

You can learn tradeoffs, failure modes, and sketch fluency. You cannot replace building. Use email for spaced retrieval; use a repo for proof.

How is this different from a newsletter of architecture links?

A newsletter forwards other people’s full posts. A curriculum sequences objectives, citations, and sketch prompts against your sources, with review.

Should I let ChatGPT generate the whole design course?

It can draft. You must ground, exclude, and review. Otherwise you will memorize fluent fiction. See hallucinations.

Why Cadensend instead of calendar reminders and Google Docs?

Reminders do not ground or lock. Docs do not send a bounded issue with a PNG fallback. Cadensend is a curriculum engine, self-hosted, MIT, not a bulk list tool.

How many issues should a self-study series have?

Five to twelve. Beyond that you will not finish, and the planner will drift. Start another series with a new outcome.

Do I need team review if I am the only learner?

You need some review, even if it is next-day you. Dangerous if you send yourself unreviewed IAM or payment “best practices” and then apply them at work.

What diagram format should I use in the emails?

PNG for the inbox, SVG or Mermaid in git, alt text as the claim. Outlook will not preserve your clever inline SVG.

Conclusion

• Narrow outcome, named sources, sketch every issue. That is the whole method.
• Email is the scheduler; citations are the tutor; you are the reviewer.
• PNG in the inbox, specs in git, no model-drawn sludge.
• Lock as you go so restudy does not rewrite what you already earned.
• Cadensend runs that loop on your machine — MIT, not ConvertKit, not a bulk sender.

Want help standing up a self-study curriculum engine? Contact HinterBuild. About · LinkedIn.