What is chaos engineering and how do Go teams apply it to test microservice resilience?

// Chaos testing in Go: inject failures in tests

// Fault injection via interface
type FaultInjector struct {
    next     UserRepository
    failRate float64 // 0.0 to 1.0
    latency  time.Duration
}

func (f *FaultInjector) FindByID(ctx context.Context, id int) (*User, error) {
    // Inject artificial latency
    if f.latency > 0 {
        select {
        case <-time.After(f.latency):
        case <-ctx.Done(): return nil, ctx.Err()
        }
    }
    // Inject random failures
    if rand.Float64() < f.failRate {
        return nil, errors.New("injected fault: database unavailable")
    }
    return f.next.FindByID(ctx, id)
}

// Test service behaviour under 50% failure rate
func TestServiceUnderFaults(t *testing.T) {
    repo := &fakeUserRepo{users: testUsers}
    faulty := &FaultInjector{
        next:     repo,
        failRate: 0.5,
        latency:  100 * time.Millisecond,
    }
    svc := NewUserService(faulty)

    // Test that service handles partial failures gracefully
    successCount := 0
    for i := 0; i < 100; i++ {
        user, err := svc.GetUserWithFallback(context.Background(), 1)
        if err == nil && user != nil { successCount++ }
    }
    // With 50% fault rate and fallback, expect at least 90% success
    if float64(successCount) < 90 {
        t.Errorf("success rate %d%% too low with fallback", successCount)
    }
}

// Tools for chaos in production:
// - Chaos Monkey (Netflix) — terminates random pods
// - Litmus (CNCF) — k8s-native chaos experiments
// - Gremlin — cloud chaos-as-a-service
// - k6 + fault injection scenarios