
  <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, 03 Aug 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.rambling-me.com/tags/request-response/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, 03 Aug 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>

    </channel>
  </rss>
