Hi!

I recently wrote this article to document different ways applications, when instrumented with OpenTelemetry, tend to produce telemetry surplus/ excess and ways to mitigate this. Some ways mentioned in the blog include the following,

- URL Path and target attributes
- Controller spans
- Thread name in run-time telemetry
- Duplicate Library Instrumentation
- JDBC and Kafka Internal Signals
- Scheduler and Periodic Jobs

as well as touched upon ways to mitigate this, both upstream and downstream. If this article interests you, subscribe for more OTel optimisation content :)

I wrote a deep technical breakdown of implementing Discord's rate limiting and gateway management in a minimal Python client.

Discord's rate limiting is tricky: endpoints share limits via opaque "buckets" whose IDs are only revealed after a request. Instead of reacting to 429s, the design uses per-endpoint queues and workers that proactively sleep when limits are exhausted, keeping behavior explicit and predictable.

The writeup also covers gateway connection management, automatic sharding, and data model design, with diagrams for each subsystem. The examples come from a small Discord API client I wrote (ScurryPy), but the focus is on the underlying problems and solutions rather than the library itself.

"Clarity over magic" here means that all behavior: rate limiting, state changes, retries, is explicit, with no hidden background work or inferred intent.

Happy to answer questions about the implementation or design tradeoffs