<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>P1 on An observer's log</title><link>https://blog.rtshkmr.com/tags/p1/</link><description>Recent content in P1 on An observer's log</description><generator>Hugo</generator><language>en</language><atom:link href="https://blog.rtshkmr.com/tags/p1/index.xml" rel="self" type="application/rss+xml"/><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>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>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>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>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>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>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>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>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>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>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>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>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>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></channel></rss>