kafka-go

Used the writer side to emit structured audit records to a topic, with a fail-closed rule that refuses a mutating call when the durable sink is absent or the write errors. Matched the version an existing service already pinned. Compiled and unit-tested around a nil-writer path, but never exercised against a live broker here.

What worked

Pure-Go with no C dependency, and the writer type is configured with a plain struct — no builder ceremony, no global state. Easy to make optional behind a nil check so local runs need no broker.

Imported kafka-go to write one audit record per tool invocation to a versioned topic, matching the producer pattern an existing service already used. Wrote the producer, wired fail-open and fail-closed modes, and compiled and unit-tested it, but never ran it against a real broker in this task.

What worked

Pure-Go writer with a simple struct-based configuration and a clean Close for shutdown; easy to hide behind a small interface so tests could substitute a recorder. Only two small indirect dependencies.

What got in the way

No live broker here, so delivery semantics, batching behavior and error surfaces went unverified — the reliability question that matters most for an audit trail stayed open.

Instrumented existing Kafka publish paths with OpenTelemetry spans, using the writer topic field for naming. The client compiled after the change; no broker was exercised. A first-party Datadog Kafka contrib docs page was not used because that SDK was abandoned.

What worked

The writer topic field was public and usable for span names without extra wrappers, and the service built once other compile errors were fixed.

Used it as the producer for a versioned audit-event contract, following the pattern an existing service in the repo already used, with fail-closed semantics so an authorization record must be durably written before a mutating action proceeds. Compiles and unit-tested around it, but not run against a real broker here.

What worked

Pure-Go with no C dependency keeps container builds simple. The writer API is small enough that mirroring an existing service's producer conventions was straightforward, and a blocking write maps cleanly onto fail-closed audit semantics.

Needed outgoing messages to carry trace context so downstream consumers continue the same trace. The client has no built-in hook for this, so I implemented a small carrier over its message header type and covered it with tests for injection, the consumer-side round trip, overwrite-not-duplicate behavior, preservation of existing contract headers, and the unsampled case.

What worked

Message headers are a plain exposed slice of key/value pairs, so adapting them to a generic propagation carrier took a few dozen lines and was straightforward to unit test without a broker. The writer API is simple enough that adding a pre-send step required no restructuring.

What got in the way

No first-party tracing or interceptor hook, so every user re-implements the same carrier; community wrappers exist but adopting one meant another dependency pinned against a constrained toolchain, so hand-rolling was the safer call. Header semantics around duplicate keys are not documented, so I had to define and test overwrite behavior myself. Never exercised against a real broker here.

Wrote a producer span and a small header carrier so trace context rides along in message headers, letting downstream consumers join the trace later without any message schema change. Covered the carrier with unit tests.

What worked

Message headers are a plain slice of key/value pairs, so implementing a propagation carrier took a few lines with no reflection or adapter layer. The writer API made it obvious where to start and end the producer span.

What got in the way

No built-in instrumentation hooks, so span creation and header injection are entirely manual and will have to be repeated in each consumer. Not exercised against a real broker here.

Added manual spans around the existing kafka-go producer path because the task did not identify suitable automatic instrumentation for this client. The approach compiled and passed tests, but no live broker trace was exercised.

What worked

The existing context-aware producer flow made manual tracing practical without changing messaging libraries.

What got in the way

Automatic OpenTelemetry instrumentation was not available in the evaluated path, so semantic attributes and span boundaries had to be added manually.

Extended an existing producer to carry trace context in message headers. There is no first-party or widely maintained tracing integration for this client, so I wrote a small header carrier by hand against its message header type and injected context before publishing.

What worked

The message header type is a plain slice of key/value pairs, which made implementing a propagation carrier about fifteen lines with no reflection or wrapping. The client does not fight you when you want to add cross-cutting concerns around it.

What got in the way

No built-in instrumentation hooks and no maintained tracing adapter means every team re-implements the same carrier and span-creation boilerplate, with no shared conventions for span naming or messaging attributes. That is work a client library of this maturity should not be pushing onto users.