Technical strategy, applied AI and modern web engineering from Bangkok.https://tahmid.space/enhttps://tahmid.space/blog/rust-shopify-headless-webhooks/https://tahmid.space/blog/rust-shopify-headless-webhooks/Remix renders the storefront, but the webhooks, internal microservices and marketing-API glue run on Rust — here's the reasoning, and where the ~40% pipeline win actually came from.Thu, 16 Jul 2026 00:00:00 GMT<p>At Marion's Kitchen Group I lead a Shopify Headless build: Remix and TypeScript on the storefront, Node.js services in the middle, and — the part that raises eyebrows — Rust handling Shopify apps, webhooks and internal microservices.</p> <h2>The webhook problem</h2> <p>Shopify webhooks are bursty, unforgiving, and multiplicative: a bulk product update or a flash-sale hour can turn a calm integration into tens of thousands of deliveries. Miss the response deadline and Shopify retries; retry storms amplify load exactly when you have the least to spare. A webhook consumer's job description is "cheap, predictable latency under load" — which is a Rust job description.</p> <p>The Rust services sit on the ingest edge: verify HMAC, ack fast, push work onto internal queues. Steady sub-millisecond handling with flat memory means the burst math stays boring, and boring is the goal.</p> <h2>Where the ~40% came from</h2> <p>The e-commerce pipeline optimization that showed up as a roughly 40% sales boost wasn't one heroic rewrite. It was the compound effect of moving slow work off the purchase path: precomputed product data instead of per-request API fan-out, Klaviyo marketing events flowing through an async API instead of the storefront request cycle, and checkout-adjacent calls held to a strict latency budget. Faster paths convert better; the platform work is the conversion work.</p> <h2>Rust where it pays, TypeScript where it flows</h2> <p>The storefront stays Remix/TypeScript — that's where iteration speed and the Shopify ecosystem live, and where hiring is sane. Rust earns its place only on hot, well-specified boundaries: webhook ingest, internal services with fixed contracts, jobs where p99 is a product feature. The boundary discipline matters more than the language choice: every Rust service has a thin, typed API and could be re-implemented in Node tomorrow without the storefront noticing.</p> <p>Polyglot backends fail when languages leak into each other's territory. Keep the seams clean and each side does what it's best at — 99.9% uptime isn't a slogan, it's the absence of interesting incidents.</p> rustshopifyheadless-commerceremixtahmidbintaslimrafi@gmail.comhttps://tahmid.space/blog/scaling-tcas-national-admissions/https://tahmid.space/blog/scaling-tcas-national-admissions/Lessons from building a national university-admission system that has one job — absorb millions of applicants in a narrow window without dropping a transaction.Thu, 16 Jul 2026 00:00:00 GMT<p>Most systems grow into their traffic. A national admission system doesn't get that luxury: TCAS (Thailand's University Central Admission System) is quiet for months, then the application window opens and a meaningful fraction of the country's students arrive at once — with deadlines, anxiety, and zero tolerance for a dropped submission.</p> <p>At Relevant Audience I worked on the TCAS platform with Node.js, TypeScript, Vue.js, TypeORM, Redis and MongoDB on AWS. These are the lessons that stuck.</p> <h2>Design for the spike, run for the idle</h2> <p>Capacity planning for burst systems is not "average load × headroom". We treated the application window as the system's real shape: microservices on ECS/EKS that scale horizontally, with the submission path isolated from everything else. Browsing programs, checking scores, editing a profile — all of that can degrade gracefully. The submit button cannot.</p> <h2>Queues are a promise, not a buffer</h2> <p>A submission that enters the system must leave it exactly once, into durable storage. Redis sat in front as both cache and pressure valve, but the contract that mattered was idempotency: retries from panicking users (and flaky mobile networks) must never double-apply. Idempotency keys on the write path cost almost nothing and eliminate a whole category of incident.</p> <h2>The database is where spikes go to die</h2> <p>MongoDB handled the flexible application documents; the relational side (via TypeORM) held the invariants. The split was deliberate: schema-rigid data where correctness rules live, document storage where the shape churns every admission cycle. Connection pools were sized for the spike and verified with load tests that replayed the previous year's traffic curve — not synthetic uniform load, which flatters you.</p> <h2>Observability earns its keep in one night</h2> <p>When the window opens, you don't debug — you read dashboards you built months earlier. Per-service latency percentiles, queue depth, and error budgets were on one screen. The difference between "we saw the p99 climb at 21:04 and shifted capacity" and "students are tweeting screenshots" is the difference between an incident and a headline.</p> <p>National-scale traffic is where architecture stops being theoretical. If your system has a day when everyone shows up, build for that day first — the other 364 will take care of themselves.</p> architecturescaleawsnodetahmidbintaslimrafi@gmail.comhttps://tahmid.space/blog/pragmatic-builder-astro-rebuild/https://tahmid.space/blog/pragmatic-builder-astro-rebuild/How a portfolio's light/dark sync bugs exposed an architectural truth — and what moving the presentation layer to Astro islands + Aceternity UI actually changed.Wed, 15 Jul 2026 00:00:00 GMT<p>My portfolio has been through four designs this year. The last rewrite wasn't about looks — it was about an architecture bug I kept patching and never fixing.</p> <h2>The bug that wouldn't die</h2> <p>The Next.js version kept theme state in a React context. The <code>&lt;html&gt;</code> class, the CSS variables, the three.js scene and the toggle each had their own idea of "current theme", synchronized by hand. I fixed a first-paint flash, a patchwork transition, and a canvas that stayed in the old theme when your pointer was idle — three real bugs, one root cause: <strong>JavaScript owned a piece of state that belongs to the document.</strong></p> <h2>The structural fix</h2> <p>In the Astro rebuild, theme is a <code>data-theme</code> attribute set by a pre-paint inline script. Every color on the site is a <code>--sys-*</code> CSS variable that re-resolves from that attribute. The toggle flips the attribute; nothing else exists. React islands can't desync because they hold no theme state at all.</p> <h2>What Astro islands changed</h2> <p>The page is static HTML with eight small hydration points — the Aceternity components (navbar, hero effects, timeline, carousels, contact form) hydrate <code>client:visible</code>, so below-fold JavaScript never competes with first paint. The trusted-collaborations wall — 36 brand icons — renders as build-time SVG with a pure CSS marquee: zero JavaScript for the section people scroll past fastest.</p> <h2>Design tokens, Material-style</h2> <p>The other lesson: utility classes without a scale produce "everything seems small and inconsistent" (my own words to the AI pair-programming with me). The fix is a token layer with Material Web's discipline — color roles with mandatory <code>on-</code> pairs, a five-step typescale, motion tokens — documented on a live <a href="/design">/design</a> page that re-renders when the theme flips.</p> <p>More on the RAG pipelines and the Shopify headless work soon — those posts belong here now that this site finally has a blog it can grow into.</p> astroarchitecturedesign-systemstahmidbintaslimrafi@gmail.com