+ {@render children()}
+
+ {subtitle}
+ {/if} +| + Feature + | + {#each options as option} + {@const Icon = getIcon(option.icon)} + selectedOption = selectedOption === option.id ? null : option.id}
+ >
+
+
+
+
+ {option.name}
+ |
+ {/each}
+
|---|---|
|
+ {feature.feature}
+ {#if feature.description}
+ {feature.description}
+ {/if}
+ |
+ {#each options as option}
+ {@const cell = getCellContent(feature.values[option.id])}
+
+ {#if cell.type === 'check'}
+ |
+ {/each}
+
{selected.realWorldExample}
+Click on a column header to see when to use each option
+{subtitle}
+ {/if} +{currentNode.description}
+ {/if} +{currentNode.reasoning}
+{subtitle}
+ {/if} +{step.description}
+ + {#if step.details} +{step.details}
+{step.tip}
++ Learn cloud infrastructure, distributed systems, and architecture patterns through + interactive diagrams, visual comparisons, and decision-guided walkthroughs. +
+ + +{category.description}
+Side-by-side analysis with "when to use" guidance
+EC2, S3, Lambda, RDS, EKS, and more
+Compute Engine, Cloud Storage, GKE, and more
+Each with interactive diagrams and real-world examples
+{concept.desc}
+Event streaming platform vs traditional message broker - understanding the fundamental differences
+ + +The fundamental architectural difference explains most of their behavior differences.
+ +{architectureDiff.kafka.description}
+ +{architectureDiff.rabbitmq.description}
+ +| Feature | +Kafka | +RabbitMQ | +
|---|---|---|
| {feature.name} | +{feature.kafka} | +{feature.rabbitmq} | +
RabbitMQ's flexible exchange types enable complex routing scenarios that Kafka cannot do natively.
+ +Kafka achieves scalability through partitions - each partition is an ordered, immutable log.
+ ++ Understanding when to use relational vs non-relational databases for your use case. +
++ Structured data in tables with relationships. Strong consistency, ACID transactions, + complex queries with JOINs. Scale vertically. Best when data structure is known and + relationships matter. +
++ Flexible schemas, horizontal scaling, eventual consistency. Different types for + different needs: documents, key-value, wide-column, graph. Best for scale, + flexibility, and specific access patterns. +
++ Instead of "SQL or NoSQL?", ask yourself these questions: +
++ Use multiple databases for different needs. PostgreSQL for transactions, Redis for caching, + Elasticsearch for search, MongoDB for flexible data. Match the database to the use case. +
++ Begin with PostgreSQL - it's versatile, well-understood, and handles most use cases. + Add specialized databases when you hit specific scaling or performance needs. +
++ Use Redis in front of your primary database. Most apps have hot data (frequently accessed) + and cold data. Cache the hot data for massive performance gains without changing your primary DB. +
+Understanding the control plane, worker nodes, and how they work together
+ + +The brain - makes decisions about the cluster
+ +The muscle - runs your actual workloads
+ +{component.description}
+Follow the journey from kubectl apply to running pod
+ +Smallest deployable unit. One or more containers that share network/storage.
+Manages ReplicaSets. Handles rolling updates and rollbacks.
+Stable network endpoint for pods. ClusterIP, NodePort, LoadBalancer.
+Non-sensitive configuration data. Injected as env vars or files.
+Sensitive data like passwords, tokens. Base64 encoded (not encrypted!).
+HTTP routing rules. Path-based routing to Services.
+For stateful apps. Stable network identity and persistent storage.
+Run pod on every node. Used for logging, monitoring agents.
+Horizontal Pod Autoscaler. Scale pods based on CPU/memory/custom metrics.
+Every pod gets a unique IP. Pods can communicate directly without NAT.
+Services provide stable virtual IPs (ClusterIP). kube-proxy routes to pods.
+NodePort, LoadBalancer, or Ingress expose services externally.
+Understanding cold starts, warm starts, and optimization strategies
+ + +No existing execution environment - must provision new container
+{phase.desc}
+Finally, your function handler runs
+Reuses existing execution environment - skips initialization
+Jump straight to your code!
+Cold start times vary significantly by language runtime
+ +| Runtime | +Cold Start | +Warm Start | +Notes | +
|---|---|---|---|
| {rt.runtime} | +{rt.coldStart} | +{rt.warmStart} | +{rt.notes} | +
{item.desc}
++ Pre-initialize a specified number of execution environments that are always ready. +
++ Snapshot initialized state and restore from cache instead of re-initializing. +
+Understanding different caching strategies and when to use each
+ + +{pattern.description}
+The most common caching pattern - walk through each step.
+When cache is full, which items should be removed?
+ +{strategy.description}
++ Many requests hit an expired cache key simultaneously, all querying the database at once. +
++ Cache contains outdated data that does not reflect current database state. +
++ Requests for non-existent data bypass cache and always hit the database. +
+| Feature | +Redis | +Memcached | +
|---|---|---|
| Data Structures | +Strings, Lists, Sets, Hashes, Sorted Sets | +Strings only | +
| Persistence | +Yes (RDB, AOF) | +No | +
| Replication | +Built-in | +No | +
| Pub/Sub | +Yes | +No | +
| Lua Scripting | +Yes | +No | +
| Memory Efficiency | +Good | +Better (simpler) | +
| Best For | +Feature-rich caching, sessions, queues | +Simple, high-throughput key-value cache | +
Understanding replication topologies, sync vs async, and consistency trade-offs
+ + +{type.description}
++ Replication lag is the delay between when data is written to the leader and when it appears on replicas. + Multiple metrics help pinpoint where the lag is occurring. +
+ +{metric.desc}
+SELECT client_addr, state,
+ pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes,
+ replay_lag
+FROM pg_stat_replication;+ System automatically promotes replica when leader fails. Fast recovery but risks split-brain. +
++ Operator manually promotes replica after verifying state. Slower but safer. +
+Route reads to replicas, writes to leader. Scale read capacity horizontally.
+Sync replica ready for instant failover. Zero data loss guarantee.
+Intentionally lag behind. Protection against accidental deletes.
+Replicas replicate to other replicas. Reduce load on leader.
+Async replica in another region. Disaster recovery and local reads.
+Replicate specific tables/databases. Schema changes, version upgrades.
++ Answer a few questions about your use case, and we'll recommend the best database for your needs. +
++ The fundamental trade-off in distributed systems: you can only guarantee two of three properties. +
+{vertex.description}
+{combo.explanation}
+ + {#if combo.viable} +{combo.useCase}
++ In any distributed system, network partitions can and will occur. When they do, + you MUST choose between consistency and availability - you cannot have both. + CA systems only exist as single-node databases. +
++ In practice, Partition Tolerance (P) is mandatory for any + distributed system - network failures are a reality. This means your real choice is between + CP (consistency over availability) and + AP (availability over consistency). +
++ The internet's phonebook - translating human-readable domain names to IP addresses. +
+Translates domain names to IP addresses
+20-120ms for uncached lookups
+Multiple caching layers for efficiency
+| Type | +Description | +Example | +Use Case | +
|---|---|---|---|
| + + {record.type} + + | +{record.description} | +{record.example} | +{record.useCase} | +
Understanding Layer 4 vs Layer 7 load balancers and when to use each
+ + +Load balancers operate at different OSI layers, determining what information they can see and use for routing decisions.
+ +| Feature | +Layer 4 (NLB) | +Layer 7 (ALB) | +
|---|---|---|
| {feature.name} | +{feature.l4} | +{feature.l7} | +
{service.use}
+