Tell me about a significant architectural trade-off you made in a Go service

Model answer

STAR structure. Situation: a high-throughput event ingestion service in Go was using a shared mutex-protected map for deduplication. At 50k events/sec it became the bottleneck — mutex contention was visible in pprof. Task: reduce contention without sacrificing correctness. Action: evaluated three options — (1) sharding the map into N buckets each with its own mutex (reduces contention by N), (2) switching to sync.Map (good for high-read, low-write skew), (3) moving deduplication to an upstream Redis layer. Chose option 1 (sharded map) because the workload was write-heavy (sync.Map performs poorly for writes) and we wanted to avoid network hops. Implemented a ConsistentHash to determine bucket, 256 shards, each with its own sync.RWMutex. Added benchmarks before and after using testing.B. Result: p99 latency dropped 4x, throughput increased to 200k/sec on the same hardware. Trade-off accepted: more complex code, harder to debug under a race detector when shard count is large.