--- title: "ZyVOP (@zyvop) | Hashnode" description: "The Developer Publishing Hub. Read the latest articles by ZyVOP on Hashnode." url: "https://hashnode.com/@zyvop" --- @zyvop # ZyVOP @zyvop · Delhi, India · Joined May 2026 The Developer Publishing Hub [Website](https://zyvop.com/) ## Comments [Absolutely. The goal isn’t to collect everything, but to capture what actually helps you identify and fix problems. Otherwise, observability itself becomes another infrastructure problem.](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126/comment/6aea176002b35ecafe273de7#reply-6aea181d992d95c8f3cfea60) Reply · Article · Nov 3 · [Observability on a Budget: Logs, Metrics, and Traces with Open-Source Tools](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126) [Good point. A successful trace doesn’t necessarily mean the agent achieved anything. LLM calls need some baseline sampling, with outcome-based checks to catch failures that latency and error rates miss.](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126/comment/6ae8929ca3de00710290368c#reply-6ae897150d864278f0f85f0f) Reply · Article · Nov 2 · [Observability on a Budget: Logs, Metrics, and Traces with Open-Source Tools](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126) [Great points. I’d recommend running the spanmetrics connector before tail sampling so RED metrics remain accurate even when traces are dropped. I’d also explicitly configure trace-aware routing, decision\_wait, num\_traces, and the memory limiter to avoid sampling inconsistencies and memory pressure as the Collector scales. These details would make the reference stack more reliable in production.](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126/comment/6ae8454bd3b927297d2ae183#reply-6ae861d79fab15872c076d64) Reply · Article · Nov 2 · [Observability on a Budget: Logs, Metrics, and Traces with Open-Source Tools](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126) [Absolutely agree. The real value of observability is how quickly you can diagnose and resolve an incident, not how much telemetry you collect. Preserving error and slow traces across service boundaries is especially important, and keeping high-cardinality identifiers out of metric labels helps control costs without sacrificing visibility. How do you usually balance tail-based sampling with the additional infrastructure and operational complexity it introduces for smaller teams?](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126/comment/6ae82b8ffa2e89bfc5ee014c#reply-6ae837e6fa2e89bfc5ee61b7) Reply · Article · Nov 2 · [Observability on a Budget: Logs, Metrics, and Traces with Open-Source Tools](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126) [That’s a fair criticism. The repository, test suite, and retry opportunities can all influence the outcome, so a benchmark needs to account for those factors before drawing conclusions about the models. I agree that the number of attempts and whether agents could revisit failing tests are especially important details. What would you consider the fairest setup for comparing these tools on real-world coding tasks?](https://hashnode.com/posts/claude-code-vs-codex-october-2026-benchmarks-pricing-and-the-real-trade-offs-rrmya/6ada0070b4da104ba2420506/comment/6ae7b29a7e53f9c370e08ea5#reply-6ae837a9ca6e073575df2195) Reply · Article · Nov 2 · [Claude Code vs Codex (October 2026): Benchmarks, Pricing, and the Real Trade-offs](https://hashnode.com/posts/claude-code-vs-codex-october-2026-benchmarks-pricing-and-the-real-trade-offs-rrmya/6ada0070b4da104ba2420506) [That’s a really good distinction. You’re right that comparing HNSW against an exact scan on halfvec only measures ANN recall within the quantized space, not the loss introduced by converting from float32 to float16. Separating those two deltas would make the trade-off much clearer, especially when nearest neighbors have very similar distances. Would you also recommend tracking ranking changes in addition to recall, since even small distance differences can affect the top-k ordering?](https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c/comment/6ae790cd4a395385cf1ef4c6#reply-6ae83736fa2e89bfc5ee5b2a) Reply · Article · Nov 2 · [Choosing a Vector Database: pgvector vs Dedicated Stores](https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c) [Great points! I especially agree about rotating secrets during offboarding. You shouldn’t have to wait until you introduce a vault to establish that habit. Adding a pre-commit scanner like Gitleaks is also a practical, low-effort step that can prevent a costly mistake. And you're right about CI/CD — secrets management needs to cover the entire deployment pipeline, not just local development. Out of curiosity, do you recommend running Gitleaks only as a pre-commit hook, or would you also run it in CI to catch anything that slips through?](https://hashnode.com/posts/secrets-management-for-small-teams-from-env-files-to-a-real-vault-opa0r/6ae6d04eab8d34e93e0a51f0/comment/6ae710f60bafa3e3243de242#reply-6ae71365bec22d2e37af943c) Reply · Article · Nov 1 · [Secrets Management for Small Teams: From .env Files to a Real Vault](https://hashnode.com/posts/secrets-management-for-small-teams-from-env-files-to-a-real-vault-opa0r/6ae6d04eab8d34e93e0a51f0) [Thanks, glad it helped. I haven’t benchmarked them head to head under herd load, so this is from the mechanics, not measurements. Delayed double-delete is probabilistic. It only works if the delay outlasts your slowest in-flight reader, and it does nothing for herds. Each delete is another miss on a hot key. Leases close the race deterministically, because a delete invalidates outstanding tokens, and they throttle the herd by letting one reader per key reload. For hot keys I’d use leases plus jittered TTLs and request coalescing, and keep double-delete as a cheap fallback. Same idea at your edge: a version number each node reports as applied tells you which nodes actually got the purge. How does CDNCA confirm that today?](https://hashnode.com/posts/caching-strategies-compared-cache-aside-write-through-and-write-behind-7t4z2/6ae2e79e8c9057215d218795/comment/6ae429150c95a18b4e67798e#reply-6ae42b95e9ef0fbc913c7be2) Reply · Article · Oct 30 · [Caching Strategies Compared: Cache-Aside, Write-Through, and Write-Behind](https://hashnode.com/posts/caching-strategies-compared-cache-aside-write-through-and-write-behind-7t4z2/6ae2e79e8c9057215d218795) [Absolutely. These are two different failure cases and should be handled differently. An empty bucket means the request may succeed after enough tokens are replenished, so a 429 Too Many Requests with a meaningful Retry-After can make sense. But if the request cost exceeds the bucket’s maximum capacity, waiting will never help. That should be rejected explicitly, with a clear explanation that the request exceeds the allowed limit rather than encouraging pointless retries. Great distinction to include in the implementation and testing strategy!](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc/comment/6ae077ed375e3174907aa8bd#reply-6ae08bfaf3b6bfa1e8940619) Reply · Article · Oct 27 · [Rate Limiting Algorithms: How to Protect Your API Without Annoying Your Users](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc) [Great points! IPv6 address rotation makes per-address limits much easier to bypass, so aggregating requests by a /64 prefix is a useful additional safeguard. On the other hand, carrier-grade NAT shows why strict IP-based limits can unfairly affect legitimate users sharing the same IPv4 address. I’d treat IP-based throttling as one layer in a broader strategy, combining it with account-level limits, API keys where applicable, and endpoint-specific quotas. The challenge is balancing abuse prevention with avoiding false positives for legitimate users. Thanks for highlighting both sides!](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc/comment/6ae087e273c73827adacde05#reply-6ae08be3dd51a132862d202b) Reply · Article · Oct 27 · [Rate Limiting Algorithms: How to Protect Your API Without Annoying Your Users](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc)