Golang / GoLang Production Patterns and Web Standards Interview Questions
What is the recommended project structure for a production Go service?
Go does not mandate a project layout, but the community has converged on a practical structure that separates concerns without over-engineering. The key principle: packages should be named for what they contain, not what they do.
myservice/ âââ cmd/ â âââ server/ â âââ main.go # entry point â only wires dependencies âââ internal/ # private packages â not importable by other modules â âââ api/ # HTTP handlers and middleware â â âââ handler_user.go â â âââ middleware.go â âââ domain/ # business logic â no infrastructure dependencies â â âââ user.go # User type, UserService interface â â âââ user_service.go # UserService implementation â âââ store/ # data access layer â â âââ postgres/ â â â âââ user_store.go # postgres implementation of UserRepository â â âââ memory/ â â âââ user_store.go # in-memory implementation for tests â âââ config/ â âââ config.go # configuration loading and validation âââ pkg/ # reusable packages (can be imported externally) â âââ httputil/ â âââ response.go # writeJSON, writeError helpers âââ migrations/ # database migration SQL files âââ docker/ # Dockerfile, docker-compose.yml âââ go.mod âââ go.sum âââ Makefile # build, test, lint targets âââ README.md // Key decisions: // internal/ prevents external packages from importing your internal logic // cmd/ can have multiple binaries (server, worker, cli) // domain/ has NO imports from store/ or api/ â dependency flows inward // Tests live alongside the code they test (*_test.go files) // main.go is thin â create, connect, start; no business logic
More Related questions...