+ Side-by-side analysis with quick “when to use” guidance. +
+Comparison guide
++ API style is a product and operational decision: clients, latency, caching, and contracts all matter. +
++ How your code runs: VMs, containers, Kubernetes, and serverless execution models. +
+Concepts + trade-offs
++ Lightweight deployment units: ship code as images and run them with predictable runtime boundaries. +
+{h.desc}
++ A VM gives you an isolated OS environment—max control, max operational responsibility. +
++ Choose the right data model and scaling strategy: SQL, NoSQL, caching, and replication. +
+Concepts + patterns
++ A family of models optimized for scale, availability, and flexible schemas—at the cost of uniform query power. +
+{m.desc}
++ With NoSQL, model around access patterns: define the queries first, then shape the data to serve them cheaply. +
++ The default choice for many products: strong correctness, powerful querying, and mature tooling. +
+{t.desc}
++ Interactive guides that turn requirements into an architecture choice. +
+Decision walkthrough
++ Use this quick decision tree to pick between serverless functions and always-on compute. +
++ Decide between queue, pub/sub, broker, and event streaming based on your requirements. +
++ Core distributed systems concepts: consistency, scaling, and performance trade-offs. +
+Interactive explainer
++ How quickly reads reflect writes in a distributed system (and what you trade for it). +
++ Reads always see the latest successful write. Simple mental model; can cost availability/latency under partitions. +
++ Replicas converge over time. Higher availability and lower latency; clients may observe stale data temporarily. +
++ After a client writes, they will see their own write on subsequent reads (session guarantees). +
++ Preserves cause→effect ordering (if A influenced B, everyone sees A before B) without full strong consistency. +
++ References are external; open in a new tab. +
++ Fast single requests and high volume are related—but optimizing one can hurt the other. +
+{c.desc}
++ Techniques to handle more traffic and data while keeping reliability, latency, and cost under control. +
+{s.desc}
+Scale up first when you can; introduce distributed complexity only when needed.
+Use SLOs and profiling to find the real bottleneck: CPU, DB, network, locks, or tail latency.
++ Decouple services with asynchronous communication: queues, pub/sub, and event-driven patterns. +
+Concepts + trade-offs
++ Systems communicate by emitting and reacting to events, enabling fanout, resilience, and evolution over time. +
+{p.desc}
++ Publish events once; multiple subscribers consume independently. Great for fanout and integrations. +
++ Queue-based messaging for background work: one message is typically handled by one consumer. +
++ How traffic reaches your system: VPCs, DNS, load balancing, and CDNs. +
+Concepts + trade-offs
++ A globally distributed caching layer that accelerates content delivery and protects your origin. +
+{b.desc}
++ A private network boundary for your workloads: address space, segmentation, and routing. +
++ Identity, encryption, and secrets: the baseline controls behind most reliable systems. +
+Core concepts
++ Protect data in transit and at rest. The hard part is key management and access control—not the cipher. +
++ Use TLS everywhere (client→edge, edge→service, service→service). Rotate certificates and enforce modern ciphers. +
++ Encrypt disks, databases, and object storage. Centralize keys, control access, and log usage. +
++ Define who can do what on which resources. Start with least privilege and strong auditability. +
++ Store and rotate credentials safely. Prefer short-lived credentials and least privilege over static keys. +
++ Pick the right storage interface: object, block, or file—each fits a different access pattern. +
+Concepts + trade-offs
++ A virtual disk you attach to a machine. Low-latency random reads/writes; typically single-writer. +
++ Shared filesystem semantics (often POSIX-like) over the network. Multiple clients can mount and read/write. +
++ Store blobs (objects) addressed by key, typically accessed via an HTTP API. Great durability and scale. +
+