
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Rambling Me</title>
      <link>https://www.rambling-me.com/blog</link>
      <description>A blog to reflect my thoughts, learnings, and observations</description>
      <language>en-us</language>
      <managingEditor>me@rambling-me.com (Dopeking)</managingEditor>
      <webMaster>me@rambling-me.com (Dopeking)</webMaster>
      <lastBuildDate>Mon, 27 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.rambling-me.com/tags/caching/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/1-how-far-request-response-goes</guid>
    <title>Scaling the API: How Far Request-Response Actually Goes</title>
    <link>https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/1-how-far-request-response-goes</link>
    <description>The honest defense of synchronous request-response. Before reaching for a broker, most systems have a long runway left in boring, well-understood techniques: stateless services, connection pooling, caching in front of the database, and read replicas. Services scale for free. The database is the ceiling. Knowing how far sync goes tells you when you actually need something else.</description>
    <pubDate>Mon, 27 Jul 2026 00:00:00 GMT</pubDate>
    <author>me@rambling-me.com (Dopeking)</author>
    <category>technology</category><category>scaling</category><category>api-backend</category><category>system-design</category><category>request-response</category><category>caching</category><category>database</category><category>practitioner</category>
  </item>

  <item>
    <guid>https://www.rambling-me.com/blog/posts/technology/scaling/orders-of-magnitude/3-the-menu-of-levers</guid>
    <title>Scaling: The Menu of Levers</title>
    <link>https://www.rambling-me.com/blog/posts/technology/scaling/orders-of-magnitude/3-the-menu-of-levers</link>
    <description>The full survey of everything you can reach for when you need to scale, on both sides of the wire. API-side levers from horizontal scale and caching to async and backpressure, and client-side levers from the CDN to optimistic UI. Each one gets a line on what it buys and what it costs. This is the map; the API and UI series are the territory.</description>
    <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    <author>me@rambling-me.com (Dopeking)</author>
    <category>technology</category><category>scaling</category><category>orders-of-magnitude</category><category>system-design</category><category>caching</category><category>load-balancing</category><category>async</category><category>practitioner</category>
  </item>

  <item>
    <guid>https://www.rambling-me.com/blog/posts/technology/scaling/ui-frontend/1-bytes-to-the-client-cheaply</guid>
    <title>Scaling the UI: Getting Bytes to the Client Cheaply</title>
    <link>https://www.rambling-me.com/blog/posts/technology/scaling/ui-frontend/1-bytes-to-the-client-cheaply</link>
    <description>The frontend track opens on the read path. The cheapest request your backend ever handles is the one it never receives, so scaling the client is largely about serving bytes from as far out as possible: CDNs and the edge, HTTP and client caching, right-sized payloads, and pagination. Plus the native-app angle, where on-device storage becomes a real cache tier.</description>
    <pubDate>Sat, 08 Aug 2026 00:00:00 GMT</pubDate>
    <author>me@rambling-me.com (Dopeking)</author>
    <category>technology</category><category>scaling</category><category>ui-frontend</category><category>cdn</category><category>caching</category><category>pagination</category><category>payload</category><category>practitioner</category>
  </item>

    </channel>
  </rss>
