singhsanjay12

We explored a closely related architecture at LinkedIn around centralized identity and policy enforcement at the action/resource boundary, which I presented at RSA Conference earlier this year in San Francisco.

Interesting to see similar architectural patterns emerging from different directions. I’d be curious where the authors see the biggest challenges in extending this model from human/service identities to autonomous agents.

We explored a closely related architecture at LinkedIn around centralized identity and policy enforcement at the action/resource boundary, which we presented at RSA Conference earlier this year. The extension to AI agents and machine-speed authorization is particularly interesting.

I wrote a deep dive on how modern reverse proxies handle thousands of concurrent requests.

The article walks through what actually happens inside a proxy when multiple requests arrive at the same time: connection handling, request queues, event loops vs thread pools, and how different implementations approach the problem.

It also compares design patterns used in systems like Apache Traffic Server, HAProxy, and Envoy, and explains why these architectural choices matter for latency, throughput, and failure behavior.

The goal was to help zoom in what happens between the client and backend when traffic spikes.

Would love feedback from folks running proxies at scale.

This matches what I've seen too.

Resolver-level resilience is often manageable centrally. The harder part is application-level recovery; especially in larger orgs where DNS behavior spans multiple teams.

Even with low TTLs or cache flush automation, apps may: resolve once at startup or hold long-lived gRPC/TCP connections, or even worse -> ignore TTL semantics entirely

So infra assumes "DNS healed," but the app never re-resolves.

fixed it

Nice. Running Unbound locally with intelligent upstream selection and caching definitely reduces blast radius from edge resolver outages.

I haven't tried Unbound but I’m curious though, how do you handle recovery behavior when the failure isn’t just recursive resolver unavailability, but scenarios like stale IPs after control plane failover, or long-lived gRPC connections that never re-resolve, or bootstrap loops where the system that needs to reconfigure DNS itself depends on DNS?

In my experience, local recursive resolvers solve availability pretty well, but recovery semantics still depend heavily on client behavior and connection lifecycle management.

Do you rely on aggressive re-resolution policies at the application layer? Or force connection churn after TTL expiry?

Would love to understand how you think about resolver-level resilience vs application-level recovery.

DNS keeps showing up in outage postmortems, but what's often missing is discussion about recovery, not just prevention.

In this post, I break down common DNS failure patterns (TTL propagation, resolver overload, control plane dependency loops) and why recovery can deadlock when your tooling itself depends on DNS.

I'd love to hear how others design around this:

Do you use DNS-independent fallbacks?

Static seed lists?

Separate control plane resolution?

Aggressive caching vs short TTLs?

Curious what patterns have worked (or failed) in real systems for folks.

This isn't a critique of DNS load balancing.

DNS works well in certain scenarios (multi-region failover, coarse traffic steering), but I've seen it misapplied in cases where faster failure detection or finer-grained routing was required.

This piece tries to outline where DNS fits well architecturally and where it starts to show limits.

For client-side LB, moving active healthcheck outside into dedicated service, wouldn't it create more reliability issues with one more service to worry about? Are there any examples of this approach being used in the industry?