<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Event-Driven on API Coding</title>
    <link>https://apicoding.com/tags/event-driven/</link>
    <description>Recent content in Event-Driven on API Coding</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 06 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://apicoding.com/tags/event-driven/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Event-Driven Architecture vs Request-Response: Choosing the Right Communication Pattern</title>
      <link>https://apicoding.com/2026/04/06/event-driven-architecture-vs-request-response-choosing-the-right-communication-pattern/</link>
      <pubDate>Mon, 06 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/2026/04/06/event-driven-architecture-vs-request-response-choosing-the-right-communication-pattern/</guid>
      <description>&lt;p&gt;The choice between request-response and event-driven communication patterns is one of the most consequential architectural decisions in distributed system design. It determines how services couple to each other, how failures propagate, how the system scales under load, and how difficult it is to trace the flow of data through the system when things go wrong. Most teams treat it as a technology choice — Kafka versus REST — when it is primarily a design choice about how services should relate to each other.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Webhooks vs Polling: The Decision Most Teams Get Backwards</title>
      <link>https://apicoding.com/2025/11/17/webhooks-vs-polling-the-decision-most-teams-get-backwards/</link>
      <pubDate>Mon, 17 Nov 2025 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/2025/11/17/webhooks-vs-polling-the-decision-most-teams-get-backwards/</guid>
      <description>&lt;p&gt;The polling versus webhooks decision is frequently made on the basis of what the API provider finds easiest to implement rather than what serves consumers best. Polling is easier to provide — it requires no additional infrastructure beyond the existing API endpoints. Webhooks require the provider to maintain delivery infrastructure, handle failures, implement retry logic, and manage consumer endpoint registration. The provider&amp;rsquo;s preference for polling is understandable. For the consumers who pay the operational cost of polling, it is not a neutral choice.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
