https://ukue.com/tags/go/ Recent content in Go on ukue.com Hugo en-us Tue, 06 Oct 2026 00:00:00 +0000 https://ukue.com/an-order-and-its-receipt-email-in-one-sqlite-transaction-with-ukues-enqueuetx/ Tue, 06 Oct 2026 00:00:00 +0000 https://ukue.com/an-order-and-its-receipt-email-in-one-sqlite-transaction-with-ukues-enqueuetx/ <p>Take a small online shop that runs as a single Go program with its data in SQLite: one file to back up and no database server to look after. When an order comes in, the shop saves it, and a receipt email goes out in the background.</p> <p>The risk is in the gap between those two steps. If the order is saved and the program crashes before the email job is queued, the customer pays and never gets a receipt. If the job is queued first and saving the order then fails, the customer gets a receipt for an order that doesn&rsquo;t exist. With a separate queue server, closing that gap takes real work, usually an &ldquo;outbox&rdquo; table in the database and a second process that copies its rows into the queue. With ukue, the queue can live inside the shop&rsquo;s own database, so the order and its job go into the same transaction, and either both are saved or neither is.</p> https://ukue.com/webhook-delivery-with-ukue-a-day-of-retries-then-dead-letters-instead-of-lost-events/ Tue, 06 Oct 2026 00:00:00 +0000 https://ukue.com/webhook-delivery-with-ukue-a-day-of-retries-then-dead-letters-instead-of-lost-events/ <p>Say a small company runs an invoicing service written in Go. Its customers want to hear about payments the moment they happen, so the service sends webhooks: an HTTP POST with the event to a URL each customer chooses. Those URLs point at servers the company doesn&rsquo;t control. They go down for maintenance, get redeployed, hit rate limits and return errors. If the service sends each webhook once, straight from the code that records the payment, every one of those hiccups loses an event, and the customer finds out weeks later when their books don&rsquo;t add up.</p>