Jieun
deserve what you want
11 posts
-
Connecting a Custom Domain with One Click — a Pipeline Built Around 'You Can't Speed Up DNS Propagation'
I built a feature to buy a domain and attach it to a blog. Bought four with the same code; all four failed differently. One cause: we ignored a wait we can't shorten (DNS propagation) and tried to do everything synchronously. Once we accepted that wait as a given, the pipeline settled into one synchronous stage plus two worker stages.
-
Taking Caddy Out of the Deploy Path — the Structural Problem Was Touching a SPOF Automatically
Every deploy took the whole stack down for 60–100 seconds. Blue-green removed most of it, but five seconds stayed at the reverse proxy — and the real cost of those five seconds was not five seconds. It was the variance: five seconds, or indefinitely. So we took it out of the deploy path entirely.
-
[Threads Marketing Agent, Part 3] Multi-Account Engagement Automation with an Anti-Detect Browser — Brain/Hands Split, CDP Driving, Detection-Aware Pacing
Part 3 of an engineering log on building a Threads marketing agent: automating engagement (likes/comments). Isolating sub-accounts with an AdsPower anti-detect browser, connecting a VPS (brain) and a Mac mini (hands) over a queue, driving the browser via CDP, and pacing it with a detection-aware random schedule.
-
[Threads Marketing Agent, Part 2] Designing a Generation Pipeline — A 4-Axis Content Model, Queue-Based Scheduling, 3-Layer Attribution
Part 2 of an engineering log on building a Threads marketing agent: a content model decomposed into four axes, an idempotent publish worker, and 3-layer attribution where 90% of clicks were bots.
-
[Threads Marketing Agent, Part 1] Designing a Crawler That Beats Three Tiers of Anti-Bot — From TLS Fingerprints to CDP Detection
Part 1 of an engineering log on building a Threads marketing agent: the bottleneck was never LLM generation — it was crawling. Tiering the strategy by which signal the anti-bot actually inspects.
-
Scaling QPS 10x in Production: 3 Strategies That Actually Move the Needle
"Make it faster" sounds vague. It isn't — it comes down to the same three moves: caching, database optimization, and pulling non-essential work out of the request.
-
[Messenger Load-Testing, Part 3] FCM to a Queue, Swallowed Failures to Sentry — Cleaning Up the Message-Send Handler
Part 3 of load-testing a messenger: pulling FCM push out of the message-send handler into a dedicated worker queue, and surfacing the failures that used to vanish into empty catches through Sentry. Two axes — isolating external I/O and handling error logs.
-
[Messenger Load-Testing, Part 2] There Was a Deadlock Hiding in AI-Generated Code — How We Replaced `unreadCount` with `lastReadAt`
42.8% HTTP error rate, 9 minutes into a load test, at 12% of the target TPS. The culprit was a single updateMany line written during AI-assisted coding.
-
[Messenger Load-Testing, Part 1] Building a Reusable Load-Test Environment — Make-based IaC, Observability, and Auth Seeding
How many TPS can a messenger's send API survive, and where exactly does it break? A 7-node mirror of production, rebuilt on demand from a single Makefile target.
-
Why You Should Never Use KeyDB as a Pub/Sub Broker for Centrifugo
KeyDB's active-replica mode looked perfect for a symmetric dual-stack chat at 100K WebSocket connections. Then I found five years of hang and deadlock issues, most still open.
-
Building a Crash-Resilient, End-to-End Meeting Recording Pipeline in the Browser
A one-hour browser recording could push the JS heap past 300 MB, and a tab crash meant losing everything. Rebuilding it as a six-stage pipeline with five-minute savepoints.
