<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Projects on Enrique Goberna</title><link>https://enriquegoberna.com/projects/</link><description>Recent content in Projects on Enrique Goberna</description><generator>Hugo</generator><language>en-US</language><atom:link href="https://enriquegoberna.com/projects/index.xml" rel="self" type="application/rss+xml"/><item><title>Order Tracking — Event-Driven Ingestion with Kafka</title><link>https://enriquegoberna.com/projects/order-tracking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://enriquegoberna.com/projects/order-tracking/</guid><description>&lt;p&gt;Order tracking looks simple until the ingestion path has to accept bursts of updates without making request latency depend on database work, while still applying events for each order in the correct sequence. The original version of this project processed tracking updates synchronously from HTTP into persistence. That was easy to reason about, but it coupled request handling to downstream processing and made independent scaling difficult.&lt;/p&gt;&#10;&lt;p&gt;The constraints mattered more than the choice of broker:&lt;/p&gt;</description></item><item><title>Snapshot Ingestion — Resilient Coordination with PostgreSQL</title><link>https://enriquegoberna.com/projects/snapshot-ingestion/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://enriquegoberna.com/projects/snapshot-ingestion/</guid><description>&lt;p&gt;A snapshot provider is an awkward system boundary. The payload can be large, the network can fail, malformed records can appear halfway through the document, and a processing worker can disappear after claiming work. None of those failure modes should become &lt;code&gt;/search&lt;/code&gt; latency or availability problems.&lt;/p&gt;&#10;&lt;p&gt;This project separates that unreliable ingestion boundary from the stable read path. A fetch worker streams the provider XML into durable staging rows, process workers claim completed work in PostgreSQL, and the API serves canonical data from PostgreSQL only. The interesting decision is not that PostgreSQL &lt;em&gt;can&lt;/em&gt; coordinate the pipeline. It is deciding that, for this workload, introducing Kafka would add more operational machinery than the problem currently earns.&lt;/p&gt;</description></item></channel></rss>