<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[SystemDesignLaws]]></title><description><![CDATA[This newsletter is easy to follow and covers core components of system design and how start-ups and big companies do it. Upgrade your career.]]></description><link>https://newsletter.systemdesignlaws.xyz</link><image><url>https://substackcdn.com/image/fetch/$s_!1UhY!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe079dd84-d487-4144-b771-e921eea5c7bf_224x224.png</url><title>SystemDesignLaws</title><link>https://newsletter.systemdesignlaws.xyz</link></image><generator>Substack</generator><lastBuildDate>Tue, 04 Aug 2026 20:55:54 GMT</lastBuildDate><atom:link href="https://newsletter.systemdesignlaws.xyz/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Jimmy Malhan]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[jimmymalhan@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[jimmymalhan@substack.com]]></itunes:email><itunes:name><![CDATA[Jimmy Malhan]]></itunes:name></itunes:owner><itunes:author><![CDATA[Jimmy Malhan]]></itunes:author><googleplay:owner><![CDATA[jimmymalhan@substack.com]]></googleplay:owner><googleplay:email><![CDATA[jimmymalhan@substack.com]]></googleplay:email><googleplay:author><![CDATA[Jimmy Malhan]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[Real-time Updates]]></title><description><![CDATA[- Real-time systems need two hops: server to client (WebSockets, SSE, long polling) and source to server (Pub/Su...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/real-time-updates</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/real-time-updates</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:39:24 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!gRdd!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3867759c-9e8b-422c-ac3b-a61cf27c9528_1840x644.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "Real-time updates require efficient push channels. I choose based on latency needs: polling for 2-5 second updates, long polling or SSE for near real-time, WebSockets when I need bidirectional low latency. The second hop is Pub/Sub or consistent hashing to fan out updates from the source to servers."</p></div><h2>The Problem</h2><p>Consider a colla&#8230;</p>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/real-time-updates">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Multi-step Processes]]></title><description><![CDATA[- Multi-step processes fail halfway: payment charged but inventory not reserved. Use workflow engines like Tempo...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/multi-step-processes</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/multi-step-processes</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:39:20 GMT</pubDate><enclosure url="https://raw.githubusercontent.com/jimmymalhan/systemdesignlaws.xyz/feature/newsletter-agent-system/newsletter/plots/svg/ms-order-fulfillment.svg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "Multi-step processes fail halfway - payment charged but inventory not reserved. I use workflow engines like Temporal or AWS Step Functions so each step is durable, failures trigger retries or compensation, and the system picks up exactly where it left off after a crash."</p></div><h2>What You Will Learn</h2><blockquote><p><strong>Approaches</strong></p></blockquote><blockquote><p>- Single-server orchestratio&#8230;</p></blockquote>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/multi-step-processes">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Dealing with Contention]]></title><description><![CDATA[- Fix race conditions with atomicity, locks, or optimistic concurrency. Scale to distributed coordination when m...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/dealing-with-contention</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/dealing-with-contention</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:39:16 GMT</pubDate><enclosure url="https://raw.githubusercontent.com/jimmymalhan/systemdesignlaws.xyz/feature/newsletter-agent-system/newsletter/plots/svg/dc-race-condition.svg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "Contention happens when two users act on the same data at once, like two people buying the last concert ticket. I fix it by making operations atomic, using locks when conflicts are common, or optimistic concurrency when they are rare. For distributed systems, I use sagas or two-phase commit. I always exhaust single-database so&#8230;</p></div>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/dealing-with-contention">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Caching for System Design Interviews]]></title><description><![CDATA[- Caching cuts latency 50x and reduces DB load by 95%+. Cache-aside with Redis is the default. Layer CDN for glo...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/caching-for-system-design-interviews</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/caching-for-system-design-interviews</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:39:12 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!4eGo!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F53bfac2b-c99b-4324-9df4-9063e7c58acd_1600x900.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "Caching stores frequently accessed data in memory so reads skip the database. I start with cache-aside using Redis as the default, add CDN for global static assets, and choose invalidation strategy based on freshness requirements. Cache-aside handles most scenarios, and I layer additional strategies only when the problem deman&#8230;</p></div>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/caching-for-system-design-interviews">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Managing Long-Running Tasks]]></title><description><![CDATA[- When a task takes more than a few seconds, do not make the client wait. Accept the request immediately (return...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/managing-long-running-tasks</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/managing-long-running-tasks</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:38:59 GMT</pubDate><enclosure url="https://raw.githubusercontent.com/jimmymalhan/systemdesignlaws.xyz/feature/newsletter-agent-system/newsletter/plots/svg/lt-sync-vs-async.svg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "For any operation that takes more than a few seconds, I return a job ID immediately and process asynchronously. A message queue decouples submission from processing. Workers pull jobs, execute them, and update status. The client polls for completion or gets a webhook callback. I add exponential backoff for retries and a dead l&#8230;</p></div>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/managing-long-running-tasks">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Handling Large Blobs]]></title><description><![CDATA[- Files should never pass through your application server. Use presigned URLs for direct upload to object storag...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/handling-large-blobs</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/handling-large-blobs</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:38:55 GMT</pubDate><enclosure url="https://raw.githubusercontent.com/jimmymalhan/systemdesignlaws.xyz/feature/newsletter-agent-system/newsletter/plots/svg/lb-naive-upload.svg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "Large files bypass my application server entirely. Clients get a presigned URL and upload directly to S3 in chunks. An S3 event triggers async processing like thumbnails or transcoding. Downloads go through a CDN. My server only handles metadata and authorization."</p></div><h2>What You Will Learn</h2><blockquote><p><strong>Upload Patterns</strong></p></blockquote><blockquote><p>- Presigned URL upload (bypas&#8230;</p></blockquote>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/handling-large-blobs">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Scaling Writes]]></title><description><![CDATA[- Scale writes in four tiers: vertical scaling with write-optimized databases, sharding to spread load, queues a...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/scaling-writes</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/scaling-writes</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:38:36 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!IrHs!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5d911796-4d50-4f9e-8e43-b382473622b9_1600x746.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "Write scaling is harder than read scaling because every write must persist to disk. I exhaust vertical scaling and database tuning first. Then I shard by partition key to spread load linearly. For bursty traffic I add queues and load shedding. For extreme volume I batch writes and use hierarchical aggregation. Each tier builds&#8230;</p></div>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/scaling-writes">
              Read more
          </a>
      </p>
   ]]></content:encoded></item><item><title><![CDATA[Scaling Reads]]></title><description><![CDATA[- Reads dominate writes 100:1. Scale in three tiers: optimize the database (indexing, denormalization), scale ho...]]></description><link>https://newsletter.systemdesignlaws.xyz/p/scaling-reads</link><guid isPermaLink="false">https://newsletter.systemdesignlaws.xyz/p/scaling-reads</guid><dc:creator><![CDATA[Jimmy Malhan]]></dc:creator><pubDate>Mon, 16 Mar 2026 17:38:14 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!zYnC!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2a1772f1-0e56-4c84-8f54-6a182f740181_1600x746.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="pullquote"><p>30-second elevator pitch: "Read traffic grows exponentially faster than writes. I handle this in three tiers: first optimize the existing database with indexes and denormalization, then scale horizontally with read replicas, and finally add caching layers. Each tier builds on the previous one, and I always start with the simplest solution."</p></div><h2>The Problem</h2><p>Co&#8230;</p>
      <p>
          <a href="https://newsletter.systemdesignlaws.xyz/p/scaling-reads">
              Read more
          </a>
      </p>
   ]]></content:encoded></item></channel></rss>