SkyRaun / Curriculum
Fifteen modules, 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.
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.
The minimum theory needed to make a real prediction. No history lessons.
The smallest system that exhibits the concept. Runnable, not pseudocode.
Commit to an answer in writing before you run anything.
Gather evidence with real tools — tcpdump, dig, curl, logs, metrics.
Inject the failure yourself. Fault injection is the curriculum, not a bonus.
Say why it happened in mechanism terms, not vocabulary terms.
Change architecture or configuration — and name the tradeoff you just bought.
Demonstrate the repair against conditions it has never seen.
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.
The real engineering problem, not the topic name.
Minimum theory. Enough to predict, no more.
The smallest useful implementation.
Inspect the system while it behaves normally.
Introduce one controlled failure.
Write down what you expect before looking.
Collect the evidence that settles it.
Why did that happen, mechanically?
Change the architecture or the config.
Behaviour before against behaviour after.
When would this matter in a real architecture?
One question derived from what you just proved.
Open any module 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.
00OrientationHow 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 module exists so the rest of the curriculum doesn't have to keep explaining itself.
01Processes, connections and socketsDiscover 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 and freshnessWhen is stale data worse than missing data?in build▾
Concepts
- Datagrams and the absence of connection semantics
- Packet loss and reordering
- Reliability versus timeliness
Labs
- A simple telemetry stream
- A packet-drop experiment
- Stale data compared against missing data
- Why drone telemetry, voice and video often prefer this model
Boundary. This does not become a realtime-media course. RTP, WebRTC and codec behaviour are out of scope.
03HTTP fundamentalsWhat you are actually sending, on the wire.in build▾
Concepts
- Request/response as a model, not a library
- Methods, headers, status codes and what they promise
- Connection reuse
- Statelessness in practice rather than in theory
Labs
- Inspect a real request on the wire
- Build a tiny server
- Compare behaviour across clients
Boundary. HTTP/2 and HTTP/3 internals, proxies and load-balancer behaviour belong to the networking track.
04Timeout ambiguityThe flagship lab. Client observation is not server reality.in build▾
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.
05Retries and idempotencyWatch a retry charge a customer twice, then make it safe.planned▾
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 POST
- Observe the duplicate side effect
- Implement idempotency and observe the changed behaviour
Incident
- “A customer was charged twice.” Diagnose from symptoms.
06DNSResolution, caching, TTL, and the failures they cause.planned▾
Concepts
- Recursive resolution and authoritative servers
- TTL and caching, including negative caching
- Record types
- Failure behaviour under stale answers
Labs
- Walk a resolution manually with
dig - Modify TTL and observe cache behaviour
- Request a nonexistent record and inspect what happens
Boundary. Sophisticated DNS routing, GeoDNS and provider architecture come later.
07TLSEncryption, identity and trust — then break the trust on purpose.planned▾
Concepts
- What encryption does and does not give you
- Certificates, identity and the chain
- The handshake as an observable sequence
Labs
- Inspect a certificate and a handshake with
openssl - Intentionally create a trust failure and read the error properly
Boundary. Not a cryptography course. No cipher internals, no maths.
08Realtime: polling, SSE and WebSocketsThree models for one requirement. Choose with reasons.planned▾
Labs
- Long-running job status by polling
- Replace it with Server-Sent Events
- Implement genuinely bidirectional behaviour over WebSockets
Architecture challenge
- A browser needs live updates but sends commands over ordinary HTTP. Which model actually matches the requirement, and why not the other two?
09RPC and gRPCContracts, protobuf, streaming — and what a retry means here.planned▾
Concepts
- RPC as a model rather than a library
- Schemas and Protocol Buffers
- Unary and streaming modes
- Deadlines, and non-idempotent retry consequences
Labs
- Implement a unary service and compare it with HTTP/JSON
- Introduce streaming and observe what changes
Boundary. Not exhaustive protobuf or production gRPC expertise.
10Messaging fundamentalsAcknowledgement, visibility, delivery semantics — before any vendor.planned▾
Concepts
- Queues and what an acknowledgement actually asserts
- Visibility and in-flight state
- Delivery semantics, honestly stated
- Consumer failure, dead-lettering, backpressure
Boundary. No vendor names in this module on purpose. You should be able to predict SQS behaviour before you meet SQS.
11SQSProcessing time exceeds the visibility timeout. Watch two workers take one job.planned▾
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.
12AMQP and RabbitMQExplicit broker topology, and how it differs from a managed queue.planned▾
Concepts
- Exchanges, queues, bindings and routing
- Acknowledgement modes
- Prefetch as a backpressure control
Boundary. Advanced RabbitMQ operations, clustering and HA policy are future material.
13KafkaA retained log is not a queue. Prove it by rewinding one.planned▾
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.
14Distributed systems foundationsWhere every earlier module combines into one problem class.planned▾
Concepts
- Partial failure as the default condition
- Ordering and deduplication
- Backpressure and retry amplification
- Consistency, partitions, replication
- Leases and failure detection
Boundary. Consensus is introduced, not mastered. The goal is that you recognise the problem class and stop reinventing it badly.
The things a $99 product 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.
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.