<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Reference on An observer's log</title><link>https://blog.rtshkmr.com/categories/reference/</link><description>Recent content in Reference on An observer's log</description><generator>Hugo</generator><language>en</language><atom:link href="https://blog.rtshkmr.com/categories/reference/index.xml" rel="self" type="application/rss+xml"/><item><title>API Gateway</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-gateway/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-gateway/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;appears in nearly every system design; the single entry point pattern&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Consistency Models</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/consistency-models/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/consistency-models/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the spectrum from linearisability to eventual consistency&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Data Model Selection</title><link>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/data-model-selection/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/data-model-selection/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the first data decision in every design; determines query flexibility, scaling, and consistency&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Deployment Strategies</title><link>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/deployment-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/deployment-strategies/</guid><description>&lt;p&gt;🟡 P2 &amp;mdash; &lt;em&gt;mentioned in designs but rarely the crux; know the trade-offs&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Leader-Follower Replication</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/leader-follower-replication/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/leader-follower-replication/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the default replication strategy for most production databases&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Networking Essentials</title><link>https://blog.rtshkmr.com/reference/archi/core/concepts/networking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/core/concepts/networking/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;foundation for reasoning about inter-service communication, latency, and failure modes&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Real-time &amp; Fan-out Patterns</title><link>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/realtime-and-fanout/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/realtime-and-fanout/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;how to push updates to many recipients; classic interview problem&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Serialisation Trade-offs</title><link>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/serialization-tradeoffs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/serialization-tradeoffs/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;DDIA Ch4 core content; underpins the gRPC proxy pattern and API versioning&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Statelessness &amp; State Management</title><link>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/statelessness/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/statelessness/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;appears in nearly every system design interview&lt;/em&gt;&lt;/p&gt;</description></item><item><title>The Three Pillars</title><link>https://blog.rtshkmr.com/reference/archi/patterns/observability/three-pillars/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/observability/three-pillars/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;the foundational framework for observability&lt;/em&gt;&lt;/p&gt;</description></item><item><title>API Design</title><link>https://blog.rtshkmr.com/reference/archi/core/concepts/api-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/core/concepts/api-design/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the craft of designing APIs; shows engineering judgement, not just pattern knowledge&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Backend for Frontend (BFF)</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/backend-for-frontend/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/backend-for-frontend/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;solves the &amp;ldquo;one API doesn&amp;rsquo;t fit all clients&amp;rdquo; problem&lt;/em&gt;&lt;/p&gt;</description></item><item><title>CAP Theorem &amp; PACELC</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/cap-theorem-and-pacelc/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/cap-theorem-and-pacelc/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the foundational impossibility result and its more nuanced successor&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Exactly-Once Semantics</title><link>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/exactly-once-semantics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/exactly-once-semantics/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the holy grail of distributed message processing; critical for payments&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Feature Flags</title><link>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/feature-flags/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/feature-flags/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;decouple deployment from release; essential for large systems&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Idempotency</title><link>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/idempotency/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/idempotency/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;critical for payment systems, Stripe&amp;rsquo;s public API design is built on this&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Index Trade-offs (B-Tree vs LSM)</title><link>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/index-tradeoffs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/index-tradeoffs/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;DDIA Ch3 deep knowledge; shows understanding of storage engine internals&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Leaderless Replication</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/leaderless-replication/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/leaderless-replication/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;Dynamo-style replication; no single leader, quorum-based&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Protocol Choices</title><link>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/protocol-choices/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/protocol-choices/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;REST vs gRPC vs GraphQL is a standard interview question&lt;/em&gt;&lt;/p&gt;</description></item><item><title>RED &amp; USE Methods</title><link>https://blog.rtshkmr.com/reference/archi/patterns/observability/red-and-use-methods/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/observability/red-and-use-methods/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;systematic approaches to choosing what to measure&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Data Modelling</title><link>https://blog.rtshkmr.com/reference/archi/core/concepts/data-modelling/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/core/concepts/data-modelling/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the first design decision that cascades into everything else: scaling, consistency, query performance&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Distributed Tracing</title><link>https://blog.rtshkmr.com/reference/archi/patterns/observability/distributed-tracing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/observability/distributed-tracing/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;following a request across service boundaries&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Failure &amp; Partial Failures</title><link>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/failure-and-partial-failures/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/failure-and-partial-failures/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the defining characteristic of distributed systems&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Idempotency Keys</title><link>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/idempotency-keys/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/idempotency-keys/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;Stripe&amp;rsquo;s public API is built on this; the implementation of idempotency for APIs&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Quorum Reads &amp; Writes</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/quorum-reads-writes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/quorum-reads-writes/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the mathematical foundation for consistency in replicated systems&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Sharding Strategies</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/sharding-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/sharding-strategies/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;how to split data across multiple databases when one isn&amp;rsquo;t enough&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Transport Protocols</title><link>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/transport-protocols/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/transport-protocols/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;understanding HTTP/2 is essential for gRPC; WebSocket vs SSE comes up in real-time designs&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Web-gRPC Proxy</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/web-grpc-proxy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/web-grpc-proxy/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;decoupling internal gRPC from external REST via a stateless proxy&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Write-Ahead Logging</title><link>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/write-ahead-logging/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/write-ahead-logging/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;the durability mechanism underlying every serious database&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Zero-Downtime Migrations</title><link>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/zero-downtime-migrations/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/zero-downtime-migrations/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;underrated staff-level signal; how to change schemas on a live system&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Consistent Hashing</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/consistent-hashing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/consistent-hashing/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;minimises data movement when nodes are added or removed&lt;/em&gt;&lt;/p&gt;</description></item><item><title>CQRS</title><link>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/cqrs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/cqrs/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;Command Query Responsibility Segregation; separate read and write models&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Double-Entry Ledger</title><link>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/double-entry-ledger/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/double-entry-ledger/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;the accounting pattern underlying every financial system&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Fallacies of Distributed Computing</title><link>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/fallacies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/fallacies/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;Peter Deutsch&amp;rsquo;s eight fallacies; useful as a shortcut reference in interviews&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Raft Consensus</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/raft-consensus/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/raft-consensus/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;the understandable consensus algorithm; know conceptually, not implementation details&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Strangler Fig (API Migration)</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/strangler-fig/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/strangler-fig/</guid><description>&lt;p&gt;🟡 P2 &amp;mdash; &lt;em&gt;Martin Fowler&amp;rsquo;s pattern for incremental migration from monolith to microservices&lt;/em&gt;&lt;/p&gt;</description></item><item><title>API Versioning Strategies</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-versioning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/api-versioning/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;how you evolve public APIs without breaking consumers&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Back-of-Envelope Estimation</title><link>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/estimation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/estimation/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;expected in every system design interview; grounds design decisions in numbers&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Cache Patterns</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/cache-patterns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/cache-patterns/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the primary tool for read scaling; multiple patterns with different consistency guarantees&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Event Sourcing</title><link>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/event-sourcing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/event-sourcing/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;store events, not state; the append-only log as source of truth&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Multi-tenancy Patterns</title><link>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/multi-tenancy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/multi-tenancy/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;directly relevant to Stripe (multi-tenant SaaS platform)&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Two-Phase Commit (2PC)</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/two-phase-commit/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/two-phase-commit/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the classical distributed transaction protocol and why it&amp;rsquo;s limited&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Cache Invalidation</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/cache-invalidation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/cache-invalidation/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;&amp;ldquo;There are only two hard things in CS: cache invalidation and naming things&amp;rdquo;&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Saga Pattern</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/saga-pattern/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/saga-pattern/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the distributed transaction pattern for microservices; critical for Stripe payment flows&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Sync vs Async Communication</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/sync-vs-async/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/sync-vs-async/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the most fundamental inter-service communication decision&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Message Queue Patterns</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/message-queue-patterns/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/message-queue-patterns/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;queues are the backbone of async architectures&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Rate Limiting &amp; Backpressure</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/rate-limiting-and-backpressure/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/rate-limiting-and-backpressure/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;definitely Stripe territory; protecting services from overload&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Timeout Strategies</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/timeout-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/timeout-strategies/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the most fundamental reliability mechanism; every network call needs one&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Load Balancing Patterns</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/load-balancing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/load-balancing/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;distributing traffic across service instances&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Batch &amp; Stream Processing</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/batch-and-stream-processing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/batch-and-stream-processing/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;two paradigms for processing large volumes of data&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Choreography vs Orchestration</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/choreography-vs-orchestration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/choreography-vs-orchestration/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;staff-level framing question: how do multi-service workflows coordinate?&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Circuit Breaker</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/circuit-breaker/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/circuit-breaker/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;prevents cascading failures by stopping calls to a failing service&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Outbox Pattern</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/outbox-pattern/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/outbox-pattern/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;solves the dual-write problem; critical for exactly-once in event-driven systems&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Retry with Backoff &amp; Jitter</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/retry-with-backoff/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/retry-with-backoff/</guid><description>&lt;p&gt;🔴 P0 &amp;mdash; &lt;em&gt;the default error recovery mechanism; Stripe definitely asks about this&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Bulkhead Isolation</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/bulkhead-isolation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/bulkhead-isolation/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;isolating failures so one component&amp;rsquo;s problems don&amp;rsquo;t sink the ship&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Ordering &amp; Causality</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/ordering-and-causality/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/ordering-and-causality/</guid><description>&lt;p&gt;🟠 P1 &amp;mdash; &lt;em&gt;how distributed systems reason about &amp;ldquo;what happened before what&amp;rdquo;&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Communication &amp; API Design</title><link>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/communication-and-apis/</guid><description/></item><item><title>Core Concepts</title><link>https://blog.rtshkmr.com/reference/archi/core/concepts/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/core/concepts/</guid><description>&lt;p&gt;Technology-agnostic fundamentals that underpin every system design. &lt;strong&gt;These are the building blocks&lt;/strong&gt;: how networks behave, how to model data, how to design APIs. Patterns build on these; without them, pattern-level answers lack grounding (see 
 
 &lt;a href="https://blog.rtshkmr.com/reference/archi/patterns/"&gt;Patterns Taxonomy&lt;/a&gt;).&lt;/p&gt;</description></item><item><title>Data Storage &amp; Retrieval</title><link>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/data-storage/</guid><description/></item><item><title>Deployment &amp; Evolution</title><link>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/deployment-and-evolution/</guid><description/></item><item><title>Domain-Specific Patterns</title><link>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/domain-specific/</guid><description/></item><item><title>Encoding &amp; Data Formats</title><link>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/encoding-and-formats/</guid><description/></item><item><title>Fundamental Concepts</title><link>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/fundamentals/</guid><description/></item><item><title>Observability</title><link>https://blog.rtshkmr.com/reference/archi/patterns/observability/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/observability/</guid><description/></item><item><title>Reliability, Consistency &amp; Synchronisation</title><link>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/reliability-and-consistency/</guid><description/></item><item><title>Scaling &amp; Performance</title><link>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.rtshkmr.com/reference/archi/patterns/scaling-and-performance/</guid><description/></item></channel></rss>