Common security patterns in microservices provide a consistent, systematic way to enforce authentication, authorization, and data protection across many independently deployed services.
Key Points: • The API Gateway pattern centralizes request validation and coarse-grained security checks at a single entry point before requests reach internal services. • Service-to-service authentication using tokens (JWT) or mutual TLS certificates ensures each service can verify the identity of the service calling it, not just end users. • The Strangler pattern can be applied specifically to security, gradually adding modern authentication to a legacy system without a risky full rewrite. • Encrypting data in transit (TLS) and at rest, along with regular vulnerability scanning, protects against interception and known exploits. • The Sidecar pattern attaches security functionality (like mTLS enforcement or policy checks) to a service as a separate co-located process, without requiring changes to the service's own code — this is essentially how a service mesh implements security.
Example: A team adopting Istio as a service mesh gets sidecar-enforced mutual TLS between every service automatically, meaning individual development teams don't need to add TLS handling code to each service themselves.
Interview Tip: A concise interview answer is:
"The common patterns I'd apply are an API Gateway for centralized request validation, service-to-service authentication via JWTs or mutual TLS, encryption in transit and at rest, and the Sidecar pattern — typically via a service mesh — to add security enforcement like mTLS without modifying each service's code directly."