SkyRaun / Curriculum

Sixteen lessons across six paths, built concept-first.

Durable queue before SQS. Publish/subscribe before SNS. Retained log before Kafka. You learn the communication model, then meet the vendors that implement it — which is why the knowledge survives your next job change.

16 lessons shipped 3 prep checkpoints capstone — included when released local-first
The loop every lab runs on

Eight steps, and the two most people skip are the ones that teach.

Predicting before you run is what converts an exercise into a belief you can be wrong about. Proving the repair is what stops a lucky pass from feeling like understanding.

01Learn

The minimum theory needed to make a real prediction. No history lessons.

02Build

The smallest system that exhibits the concept. Runnable, not pseudocode.

03Predict

Commit to an answer in writing before you run anything.

04Observe

Gather evidence with real tools — tcpdump, dig, curl, logs, metrics.

05Break

Inject the failure yourself. Fault injection is the curriculum, not a bonus.

06Explain

Say why it happened in mechanism terms, not vocabulary terms.

07Fix

Change architecture or configuration — and name the tradeoff you just bought.

08Prove

Demonstrate the repair against conditions it has never seen.

What a lab actually contains

Every lab answers the same twelve questions.

The shape is deliberately repetitive. Once you know it, you stop spending attention on navigation and spend it on the system instead.

01Why this matters

The real engineering problem, not the topic name.

02Mental model

Minimum theory. Enough to predict, no more.

03Build

The smallest useful implementation.

04Observe

Inspect the system while it behaves normally.

05Break

Introduce one controlled failure.

06Predict

Write down what you expect before looking.

07Observe again

Collect the evidence that settles it.

08Explain

Why did that happen, mechanically?

09Modify

Change the architecture or the config.

10Compare

Behaviour before against behaviour after.

11Production consequence

When would this matter in a real architecture?

12Interview question

One question derived from what you just proved.

Lesson by lesson

Open any lesson to see its concepts, labs and boundary.

Each one states what it deliberately does not cover. A course that claims to teach everything about TCP and Kafka and consensus in one purchase is lying to you; the boundary is how you know this one isn't.

shipped readable and runnable today
prep optional calibration checkpoint — skip it if you have it covered
included the capstone: part of your purchase, lands when released
Start here

Orientation, plus an optional Python warm-up before anything networked.

00How SkyRaun worksHow to use the laboratory, and how to think inside it.shipped

Concepts

  • How labs are structured
  • Forming a hypothesis you can be wrong about
  • Gathering evidence instead of impressions
  • Documenting a finding so it stays useful

Boundary. No networking content. This lesson exists so the rest of the curriculum doesn't have to keep explaining itself.

PREPPython syntax calibrationSeven quick checks on the small Python forms these labs reuse.prep

What it covers

  • Names, keyed values and sequences
  • Comparisons and boolean branches
  • Debug prints, loops and indentation

Boundary. Skip it if you already have Python covered — the systems work stays the hard part either way.

Path · Transport & Protocols

How bytes, datagrams, and HTTP messages cross process boundaries.

01TCP byte streamsDiscover that TCP hands you bytes, not messages — then repair the decoder.shipped

Concepts

  • Processes, ports, sockets, loopback
  • Connection state and lifecycle
  • Application messages versus byte streams
  • Framing rules and decoders

Labs

  • A tiny TCP client and server
  • Message-framing failure under an 8-byte read buffer
  • The same bug hidden by friendly timing, then exposed by partial writes
  • Repair the decoder and prove it against hostile boundaries

Boundary. Not all of TCP. Congestion control, retransmission behaviour and Linux networking internals are reserved for a dedicated networking track.

02UDP datagrams and freshnessWhen is stale data worse than missing data?shipped

Concepts

  • Datagrams and the absence of connection semantics
  • Packet loss and reordering
  • Reliability versus timeliness

Labs

  • A telemetry sender and receiver over datagrams
  • Make loss and reordering visible
  • Stop stale telemetry from moving state backward
  • Prove the freshness policy independently for each sensor

Boundary. This does not become a realtime-media course. RTP, WebRTC and codec behaviour are out of scope.

03HTTP on the wireWhat you are actually sending, on the wire.shipped

Concepts

  • Request/response as a model, not a library
  • Methods, headers, status codes and what they promise
  • Content-Length as a byte contract, not a character count

Labs

  • Inspect a real HTTP/1.1 exchange on the wire
  • Expose a Unicode Content-Length defect that ASCII concealed
  • Repair the boundary using encoded bytes rather than characters

Boundary. HTTP/2 and HTTP/3 internals, proxies and load-balancer behaviour belong to the networking track.

Path · Reliability & Delivery

What timeouts and retries can prove, hide, or duplicate.

04Timeouts and unknown outcomesThe flagship lab. Client observation is not server reality.shipped

The scenario

  • A request arrives and the operation commits
  • The response is delayed past the client's patience
  • The client times out and reports failure
  • You are asked whether the operation failed — and discover nobody can know

Why it comes early

  • It is the shortest path to a genuine distributed-systems insight
  • Every retry, idempotency and messaging module afterwards depends on it

Boundary. One concept only. Retry mechanics and idempotency keys are the next module, deliberately.

05Safe retries and idempotencyWatch a retry charge a customer twice, then make it safe.shipped

Concepts

  • Retry semantics and who owns them
  • Duplicate side effects
  • Idempotency, and idempotency keys
  • At-least-once delivery as a default reality

Labs

  • Retry an unsafe request and observe the duplicate side effect
  • Connect attempts with a stable idempotency key
  • Replay the original result, and reject conflicting reuse of a key
Path · Naming & Trust

How clients turn names, cached answers, certificates, and trust policy into service identity.

06DNS caching and TTLResolver memory is not authoritative truth.shipped

Concepts

  • Resolvers versus authoritative servers
  • TTL and cache lifetime
  • Missing records and failure behaviour
  • Stale answers served after expiry

Labs

  • Run a nameserver and a caching resolver locally
  • Expose an answer served after its TTL expired
  • Repair the cache to refresh stale state without discarding useful hits

Boundary. Sophisticated DNS routing, GeoDNS and provider architecture come later.

07Digital signaturesWhat a signature proves — and the question it cannot answer.shipped

Concepts

  • A signature binds exact bytes to one key pair
  • Detecting changed data, and a changed signer
  • The trust question signature verification cannot answer

Boundary. Not a cryptography course. No cipher internals, no maths.

08Certificates and chain trustRoot to leaf: who authorised whom.shipped

Concepts

  • Subject and issuer key pairs, kept separate
  • Path discovery versus trust
  • Authorising a service key only after every parent authorised its child

Labs

  • Inspect real root, intermediate and leaf certificates
  • Run valid, tampered and rogue chains through the pipeline
  • Prove the chain policy stage by stage
09TLS 1.3: authenticate a live serverEncryption is not identity.shipped

Concepts

  • What encryption does and does not give you
  • The certificate chain and the live private-key proof
  • Hostname verification as part of identity

Labs

  • Trace a live TLS 1.3 handshake against a real server
  • Connect with the wrong hostname and read the error properly
  • Restore mandatory chain and hostname verification

Boundary. Not a cryptography course. No cipher internals, no maths.

Path · Communication Models

How systems choose who initiates updates and how long a connection stays useful.

10Polling and Server-Sent EventsTurn repeated snapshots into one server-driven stream.shipped

Labs

  • Measure polling's repeated requests against one long-lived response
  • Separate the SSE media type from SSE framing
  • Repair one long-lived response to dispatch server-driven updates
11WebSocketsA reconnect that silently skips state — and the replay policy that recovers it.shipped

Labs

  • Trace a real HTTP Upgrade
  • Separate transport delivery from application acknowledgement
  • Expose a reconnect that silently skips state, then build a retained-log replay policy

Architecture challenge

  • When is a WebSocket the honest fit — and when do polling or SSE match the requirement better?
PREPGo syntax and tooling calibrationEnough Go that Lesson 12 can stay about gRPC.prep

What it covers

  • Compile a real Go package
  • A typed branch over structs and slices, returning two results
  • Prove it with go test

Boundary. Skip it if Go syntax and tooling are already familiar.

12Protocol Buffers and gRPCContracts, generated APIs — and a deadline that actually cancels work.shipped

Concepts

  • RPC as a model rather than a library
  • Schemas and Protocol Buffers
  • Deadlines, cancellation, and what a retry means here

Labs

  • Trace a Protocol Buffer schema into generated gRPC APIs
  • Expose a configured timeout that never reaches the call
  • Attach a real deadline and watch cancellation stop server work

Boundary. Not exhaustive protobuf or production gRPC expertise.

Path · Messaging & Event Systems

How durable delivery, acknowledgements, routing, and replay change failure handling.

PREPDocker and ComposeDeclare, run, probe and tear down a container environment.prep

What it covers

  • The CLI versus the engine
  • Author a Compose service and publish a loopback port
  • Cross the boundary with a real request, then tear down cleanly

Boundary. Just enough Docker for the broker lessons ahead. Skip it if Compose is already daily kit.

13Durable queue fundamentalsAcknowledgement, visibility, delivery semantics — before any vendor.shipped

Concepts

  • Queues and what an acknowledgement actually asserts
  • Ready, in-flight, acknowledged, recovered and dead-letter state
  • Delivery semantics, honestly stated
  • Consumer failure, dead-lettering, backpressure

Labs

  • Crash a worker mid-job and watch redelivery rather than silent loss
  • Route a poison message to the dead-letter state

Boundary. No vendor names in this lesson on purpose. You should be able to predict SQS behaviour before you meet SQS.

14SQS visibility and duplicate deliveryProcessing time exceeds the visibility timeout. Watch two workers take one job.shipped

Concepts

  • A managed durable queue
  • Visibility timeout and the delete-as-acknowledgement model
  • Duplicate delivery as normal, not exceptional
  • Dead-letter queue behaviour

Flagship lab

  • Set the visibility timeout below the worker's real processing time and watch what happens

Incident

  • “Why did two workers process the same job?” — with misleading signals present

Boundary. Not every SQS feature, and not general AWS architecture.

15RabbitMQ and AMQPExplicit broker topology, and how it differs from a managed queue.shipped

Concepts

  • Exchanges, queues, bindings and routing
  • Acknowledgement modes
  • Prefetch as a backpressure control

Labs

  • Route publications through direct, fanout and topic bindings
  • Bound a consumer's unacknowledged window with prefetch
  • Recover in-flight work after consumer loss

Boundary. Advanced RabbitMQ operations, clustering and HA policy are future material.

16Kafka foundations and replayA retained log is not a queue. Prove it by rewinding one.shipped

Concepts

  • The append-only retained log
  • Partitions, offsets and ordering guarantees
  • Consumer groups and rebalancing
  • Retention and replay

Labs

  • Producer and consumer
  • Kill the consumer mid-flight
  • Rewind an offset and observe replay

Incident

  • The side effect happened but the offset never committed. What happens next?

Boundary. Deep enough for correct mental models. Cluster operations, controller internals and production tuning belong to a dedicated Kafka track.

Path · Distributed State & Coordination

How evidence from several layers combines during a distributed-systems incident.

17Distributed systems capstoneWhere every earlier lesson combines into one incident.included

Concepts

  • Partial failure as the default condition
  • Ordering and deduplication
  • Backpressure and retry amplification
  • Leases and failure detection

Capstone — included when released. This is part of the Foundations purchase, not an upsell. It is not downloadable yet; the day it releases, it lands in your existing clone with git pull, at no extra cost — beta buyers included.

Deliberately not in Foundations

The things a $199 course — let alone a $99 beta — should not claim to teach.

Foundations gives you enough context to understand why these matter and to ask sharp questions about them. Implementation and operational depth belong to focused tracks, which may or may not ever exist — no dates, no promises.

RaftPaxosconsensus implementationdistributed locks database replication internalsconsistency models in depthKafka operations Kubernetes internalsLinux kernel networkingeBPFservice meshes advanced QUICdatabase internalsdistributed storage advanced load balancingCDN architecturemulti-region systems large-scale incident response

Judge it by a whole lab, not a syllabus.

Lab 01 is published in full, free, with the experiments, the evidence and the repair. If the writing works for you, the rest will too. Beta price $99 · then $149 founder · $199 full price.