<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
  <channel>
    <title>InfoQ - Apache Flink - Articles</title>
    <link>https://www.infoq.com</link>
    <description>InfoQ Apache Flink Articles feed</description>
    <item>
      <title>Article: The Schema Proliferation Problem in Kafka and Flink Pipelines: How to Solve It</title>
      <link>https://www.infoq.com/articles/schema-proliferation-problem/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=Apache+Flink-articles</link>
      <description>&lt;img src="https://res.infoq.com/articles/schema-proliferation-problem/en/headerimage/schema-proliferation-problem-header-1779270222602.jpg"/&gt;&lt;p&gt;Schema proliferation builds slowly and gets expensive fast. One schema per event type feels right until there are ten tables, union queries spanning all of them, and a single field rename touching every schema. Discriminator-based schema consolidation collapses that to two tables, turning multi-table unions into a single query, while new variants are additive and don't break existing consumers.&lt;/p&gt; &lt;i&gt;By Spoorthi Basu&lt;/i&gt;</description>
      <category>Java</category>
      <category>Apache Kafka</category>
      <category>Apache Iceberg</category>
      <category>Schema</category>
      <category>Apache Flink</category>
      <category>Architecture &amp; Design</category>
      <category>Development</category>
      <category>article</category>
      <pubDate>Mon, 25 May 2026 13:00:00 GMT</pubDate>
      <guid>https://www.infoq.com/articles/schema-proliferation-problem/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=Apache+Flink-articles</guid>
      <dc:creator>Spoorthi Basu</dc:creator>
      <dc:date>2026-05-25T13:00:00Z</dc:date>
      <dc:identifier>/articles/schema-proliferation-problem/en</dc:identifier>
    </item>
  </channel>
</rss>
