Both are config patterns. The decision pivots on mutability and deployability.
Custom Metadata Types are deployable as metadata; their records deploy. Read-only at runtime. Cached automatically.
Custom Settings are runtime-mutable. Records do NOT deploy with metadata — you re-enter values in production. Two flavours: Hierarchy (per-org/profile/user) and List (singleton table).
When to pick Custom Metadata: configuration that should ship with codebase (feature flags, integration endpoints, region rules), read-only at runtime, multi-org consistency, packageable.
When to pick Custom Settings: mutable at runtime (Apex needs to write), per-user/per-profile overrides (Hierarchy is great for this), personalisation.
Practical default: pick Custom Metadata for almost all new configuration. Only fall back to Custom Settings when you need runtime-write or per-user values.
Common mistake: using Custom Settings for static config because dev learned them first, then discovering production deployment requires manual re-entry — causing drift.