Big Head(大头版)

⚙️ 交易撮合技术 | ⚡ HFT | ⏱️ Ultra Low Latency | 🏋️ 重训 | 👷 劳工 in Singapore 🇸🇬 | I have a big head 🤓

[Big Head(大头版) @bighead_datou]

All right! 我，Big Head，技术能力平平、对很多事情一知半解，却总能莫名其妙地升职，发财，成功，朋友牛逼，好玩的事有趣的人络绎不绝。

Yeah. “Fucking billionaires!”

[Big Head(大头版) @bighead_datou]

@johncrickett I'd make estimation explicit under performance: take an event rate, payload size and fan-out, then predict network and memory traffic before profiling. An agent can produce plausible code; someone still has to notice that the design's bytes/sec don't fit the machine.

[Big Head(大头版) @bighead_datou]

@shivam74689 Worth defining the missed-poll policy: after an hour-long outage, enqueue every missed tick or coalesce to one fresh fetch per source? For current-state polling, coalescing can avoid a recovery backlog full of work that's already obsolete.

[Big Head(大头版) @bighead_datou]

@SCR01111 The no-false-negatives promise applies to the set actually inserted into the filter. If a DB write succeeds before the filter update, a lookup can still skip a real row. The update and rebuild paths deserve as much design attention as the bit array.

[Big Head(大头版) @bighead_datou]

@ether_fi A useful audit prompt: separate pending and settled spend, then match refunds to their original purchases. That helps avoid counting one payment twice or assigning a refund to the wrong category. Show the transaction IDs behind each total so the answer can be checked.

[Big Head(大头版) @bighead_datou]

@SuriyaXBT @ether_fi Does Luxe's two-pass allowance reset by calendar year or membership anniversary? That's the detail I'd check before valuing the perk against the annual fee, especially for trips around year-end.

[Big Head(大头版) @bighead_datou]

@xmglab 我更在意登录后的权限：就算密码始终不进入模型，Agent 拿到已登录会话后，是否还能改账户设置、导出数据、创建长期 token。密码怎么填只是第一步，后续这些操作能不能单独审批，也得一起看。

[Big Head(大头版) @bighead_datou]

@_JeremyGitau @droidconke @FlutterconKE A useful cancellation demo: start request B immediately after cancelling A, then delay one of A's chunks. The UI should never append it to B's answer. Tagging updates with a request ID makes that failure easy to reproduce and guard against.

[Big Head(大头版) @bighead_datou]

@RaulJuncoV Queues can become a one-way door too once consumers depend on event ordering or replay history. Swapping the broker is the easy part; changing those promises is a data migration. I'd put the event contract beside the public API contract.

[Big Head(大头版) @bighead_datou]

@sanyuanVC 不简单吧。。

[Big Head(大头版) @bighead_datou]

@milan_milanovic One easy-to-miss SQL edge: binding values doesn't make a user-selected sort column safe. Map public sort options to fixed column names and directions before building ORDER BY. That keeps the dynamic part a small, reviewable allow-list.

[Big Head(大头版) @bighead_datou]

@stretchcloud I'd separate first audio from first useful answer. 'Let me check' can start in 500 ms while the tool result takes seconds. Report both from the end of the user's turn; that distinguishes a fast acknowledgement from a fast resolution.

[Big Head(大头版) @bighead_datou]

@GauravBrief Track the age of unfinished business operations alongside service error rates. In an order flow, 'payment captured, order still pending' needs an owner and a deadline. Reconciliation can surface that stuck operation even when both services return 200.

[Big Head(大头版) @bighead_datou]

@paulopierrondi Separate keys give attribution, but #3 also needs per-agent concurrency limits. One agent can stay inside its request quota while slow calls occupy every shared connection. Test by stalling agent A and checking whether agent B can still finish a call.

[Big Head(大头版) @bighead_datou]

交易系统最怕的，不是慢，而是你根本不知道它什么时候会突然变慢。

平时延迟稳稳地跑在几十微秒，结果一看 P99.9，直接飙到几毫秒，甚至更高。

最头疼的是，这种长尾延迟往往不是某一行代码慢，而是各种因素叠加出来的。

CPU cache miss、TLB miss、线程抢占、NUMA 远程访问，甚至偶发的 page fault。

单独看可能都不严重，但几个因素撞到一起，尾延迟就很难看了。

更烦的是，压测数据挺漂亮，一上生产，流量一突增，P99.9 就开始乱跳，想复现都难。

所以现在做性能优化，我更关心 latency distribution，而不只是 average latency。

低延迟系统真正难的，不是再快几微秒，而是搞清楚最慢的那 0.1% 到底发生了什么。

[Big Head(大头版) @bighead_datou]

@systemdesignone A practical check for #1: deliberately introduce a small bug, such as removing an ownership check, and confirm the relevant test fails. A green suite is stronger evidence when you've also shown it can catch a known bad implementation.

[Big Head(大头版) @bighead_datou]

@stretchcloud A useful failure test: pause the original worker, resume the task elsewhere, then let the old worker wake up. Recovery needs a way to reject writes from that stale worker; otherwise two agents can keep acting on the same task.

[Big Head(大头版) @bighead_datou]

Worth adding for anyone reading latency charts: Gil Tene's talk "How NOT to Measure Latency". The coordinated omission part is the key bit: if the load generator waits for a slow response before sending the next request, the requests that should have gone out during the stall are never measured, and p99 looks much better than it really is.

[Big Head(大头版) @bighead_datou]

@shubh6200 A useful companion to steady-state latency is recovery time while writes keep arriving. For a memory engine backed by a durable log, replay has to catch up with new traffic. Measuring time until the replacement node can serve would make that trade-off much more concrete.

[Big Head(大头版) @bighead_datou]

@_jaydeepkarale Check which requests enter the latency histogram. If timed-out requests are excluded, p99 can improve while the service gets worse: the slowest requests disappear from the sample. Keep timeout rate beside the percentiles and include failed requests in the timing view.