标签：#eventdriven

If you need real-time BTC conversion (USD and BRL), polling an API every few seconds is usually not enough. A better approach is streaming quotes with WebSockets and calculating conversions as events arrive. Why WebSockets for BTC conversion? With WebSockets, your app keeps one open connection and receives new prices instantly. Benefits: Lower latency than polling Fewer HTTP requests Better user experience for real-time values Trade-offs: You must handle reconnects Need heartbeat/health checks Must validate and normalize incoming messages Real-time conversion model For BTC conversion, a common model is: Stream BTC/USD Stream USD/BRL Calculate BTC/BRL = BTC/USD × USD/BRL This avoids waiting for a separate BTC/BRL endpoint and keeps conversion logic transparent What is a “tick”? A tick is one market update event. Example: BTCUSD changed to 64210.50 at timestamp t . In this article, each tick has: pair : market identifier ( BTCUSD , USDBRL ) price : latest value for that pair ts : event timestamp Why this matters: conversion state should always be derived from the latest ticks . Minimal WebSocket client (TypeScript) This client only transports responsibilities: Connect Receive messages Parse and normalize into a consistent shape Notify listeners Reconnect on disconnect type MarketTick = { pair : string ; // e.g. "BTCUSD" or "USDBRL" price : number ; ts : number ; }; class WsFeedClient { private ws ?: WebSocket ; private listeners : Array < ( tick : MarketTick ) => void > = []; constructor ( private readonly url : string ) {} connect () { this . ws = new WebSocket ( this . url ); this . ws . onopen = () => console . log ( " [ws] connected " ); this . ws . onmessage = ( event ) => { try { const data = JSON . parse ( String ( event . data )); // Normalize external payload into internal contract const tick : MarketTick = { pair : String ( data . pair ), price : Number ( data . price ), ts : Number ( data . ts ), }; // Basic guard if ( ! tick . pair || Number . isNaN ( tick

At my workplace, I worked on an ERP platform used by fashion businesses to manage customers, body measurements, products, orders, invoices, inventory, staff, and other day-to-day operations. Each business also had a public storefront where customers could browse products and check out. The storefront started as a simple sharing feature. Businesses could publish products, copy a link, and send it to customers outside the main workspace. That worked well because the storefront was mostly a product catalogue, and most of the sales process still happened after the customer contacted the business. As the platform evolved, the storefront became much more than a catalogue. Customers were discovering businesses through shared links, browsing products, placing an order, and tracking orders directly from the storefront. That introduced new technical requirements around branded storefronts, SEO, server-rendered metadata, public checkout, pricing, and analytics. This article explores how I designed the storefront around wildcard subdomains, immutable shop identities, server-side shop resolution, and a scalable analytics pipeline. Table of Contents Giving the Storefront Its Own Identity Business Names, Reserved Names, and Subdomains Resolving a Storefront Active and Inactive Storefronts Location and Currency Product Pages and Share Previews Storefront Event Ingestion Processing Raw Events Counting Unique Visitors With HyperLogLog Domain Routing and Local DNS 1. Giving the Storefront Its Own Identity The original storefront was fairly simple. It was a React application that fetched a business and rendered its products. Beyond that, there wasn't much to it. There were no branded storefronts, analytics, subdomains, or even a separate identity beyond the business itself. Introducing those capabilities meant the storefront needed its own data model. I introduced a dedicated shop entity to represent the public storefront. The business remained the source of operational data such as cu

The RabbitMQ upgrade looked like a straightforward infrastructure task: move from RabbitMQ 3.X to 4.X, provision the new broker, review the client setup, confirm queues still declare correctly, restart consumers, watch the logs, and move on. But infrastructure upgrades rarely test only infrastructure. They also test the assumptions your application has been making for years. In this case, the upgrade forced a more important question: is our messaging system reliable by design, or has it simply been relying on stable conditions? That distinction matters because a message queue can appear healthy when the broker is running, the network is stable, consumers are alive, and messages are acknowledged quickly. But production systems are not judged only by how they behave when everything is fine. They are judged by how they behave during restarts, closed channels, slow handlers, bad configuration, deployment windows, and partial failure. The RabbitMQ upgrade exposed those edges. It revealed assumptions around connection lifecycle, acknowledgements, dead-letter routing, retry behavior, observability, and operational simplicity. The real lesson was not just how to upgrade RabbitMQ. The real lesson was how to build a messaging layer that is easier to operate, easier to reason about, and safer to fail. Simplicity Is an Operational Feature One of the first things the upgrade exposed was complexity. Over time, messaging code can quietly become a small internal framework. A connection helper becomes a connection manager. A consumer wrapper becomes a consumer framework. Retry helpers appear, dead-letter helpers appear, failure handlers appear, and monitoring logic gets layered on top. Each addition may have been reasonable when introduced, but during an incident, complexity has a cost. Every abstraction becomes another place to inspect. Every helper becomes another assumption to validate. Every unused file becomes a possible source of false confidence. RabbitMQ integration code doe

TL;DR Retailers process thousands of inventory transactions every second across physical stores, eCommerce platforms, warehouses, suppliers, and fulfillment centers. Yet many inventory systems still rely on scheduled synchronization, causing stock levels to become outdated within minutes. The result is overselling, delayed replenishment, inaccurate inventory visibility, and avoidable stockouts. Apache Kafka enables real-time inventory management by treating every inventory movement as an event that is streamed the moment it occurs. Sales, returns, warehouse transfers, supplier deliveries, and IoT sensor updates are continuously processed to maintain a consistent inventory view across all retail systems. This event-driven approach helps retailers improve inventory accuracy, automate replenishment, detect stockouts before they occur, and respond to changing demand in near real time. In this guide, you'll learn how Apache Kafka powers real-time inventory management, explore a production-ready reference architecture, understand how inventory events are processed across retail systems, and discover implementation best practices for building scalable, resilient inventory streaming applications. Introduction Retail inventory management has evolved far beyond tracking products on warehouse shelves. Today's retailers operate across physical stores, eCommerce platforms, online marketplaces, distribution centers, and supplier networks, where inventory levels change continuously throughout the day. Every sale, return, warehouse transfer, supplier delivery, and inventory adjustment impacts product availability, making accurate inventory visibility essential for delivering a seamless customer experience. However, many retailers still rely on scheduled synchronization between Point-of-Sale (POS) systems, Warehouse Management Systems (WMS), Enterprise Resource Planning (ERP) platforms, and online storefronts. While these systems perform different functions, they all depend on accur

A conversation between Uncle (a backend architect) and Nephew (a curious developer) about events, publishers, subscribers, Redis Pub/Sub, RabbitMQ, and Kafka The Beginning: What is an Event? 👦 Nephew: Uncle, I see words like "Redis Pub/Sub", "RabbitMQ", "Kafka" everywhere in job descriptions. What do they all do? Are they the same thing? 👨‍🦳 Uncle: (smiles) No, they're different. But before I confuse you with names, let me ask you something. Have you ever watched the news on TV? 👦 Nephew: Yes uncle, every morning! 👨‍🦳 Uncle: Perfect! So when the news channel says "Breaking News: India won the cricket match" - what happened? 👦 Nephew: Something important occurred... and they announced it! 👨‍🦳 Uncle: Exactly! That "something important occurred" is called an Event . In software, when something happens - like a user placing an order, a payment succeeding, or a file uploading - that's an event. 👦 Nephew: So event = something that happened? 👨‍🦳 Uncle: Yes! Think of it as news. When you place an order at Zomato, that's an event. When you get a payment notification from Google Pay, that's an event. When someone follows you on Instagram, that's an event. 👦 Nephew: Okay, I get it. But uncle, why is this "event" concept important? I can just write code directly, right? 👨‍🦳 Uncle: Ah! That's where the real story begins... The Problem: Spaghetti Code 👨‍🦳 Uncle: Imagine you own a food delivery company. A customer places an order. Now, what all needs to happen? 👦 Nephew: Umm... save the order, send email confirmation, alert the restaurant? 👨‍🦳 Uncle: Good! Let me write the code without events: function placeOrder ( orderId ) { saveOrder ( orderId ); sendEmailConfirmation ( orderId ); sendSMSNotification ( orderId ); notifyRestaurant ( orderId ); updateAnalyticsDashboard ( orderId ); addLoyaltyPoints ( orderId ); updateInventory ( orderId ); } Now, one day your boss says "Also send WhatsApp notification". What do you do? 👦 Nephew: Add another function call in the same code? 👨‍🦳 Unc