Authentication (AuthN) and authorization (AuthZ) are the two questions every request must answer before it touches your business logic. They are distinct concerns — confusing them is one of the most common security mistakes in distributed systems. AuthN is identity: proving you are who you claim to be. AuthZ is permission: determining what that identity is allowed to do. Getting either wrong usually means getting breached.

OAuth 2.0 is an authorization framework — it allows a user to grant a third-party application limited access to their resources without sharing their password. The key concept is delegation: the user authorizes the app, the app receives an access token, the app uses that token to call APIs on the user's behalf. OAuth 2.0 alone does not tell the app who the user is — it only grants access.

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It adds an ID token (a JWT containing user identity claims: sub, email, name) alongside the access token. This is how "Sign in with Google" works — OAuth 2.0 handles the authorization flow, OIDC provides the identity.

The traditional network security model was simple: everything inside the firewall is trusted, everything outside is not. That model is dead. Cloud services, remote workers, microservices spanning multiple networks, third-party integrations — the perimeter no longer exists. Zero Trust assumes that any request — internal or external — could be malicious, and verifies every single one. It is not a product you buy; it is an architecture principle you implement layer by layer.

Every service, user, and process should have the minimum permissions required to do its job — nothing more. If a service only needs to read from one database table, it should not have write access, and certainly not admin access. This principle is foundational to Zero Trust — limiting blast radius when a component is compromised.

Every significant breach in the past decade traces back to a leaked credential — an API key committed to Git, a database password in an environment variable exposed through a debug endpoint, an expired certificate that nobody rotated. Secrets management is not glamorous work, but it is the difference between "security incident" and "existential breach." The principle is simple: no human should know production secrets. No secret should be stored where code is stored.

Rotation: secrets should rotate automatically on a schedule (30–90 days). The secrets manager updates the credential at both ends — the service gets the new value on next request, the target (DB, API) accepts the new credential. Zero downtime. Detection: tools like git-secrets, truffleHog, and pre-commit hooks scan for accidentally committed secrets before they reach the repository.

Monitoring tells you when something is broken. Observability tells you why it is broken. In a monolith, a stack trace is usually enough. In a distributed system with 50 services, a single request touches a dozen processes across multiple machines — you need correlated signals across all of them to understand a failure. The three pillars — logs, metrics, and traces — are not redundant; they answer fundamentally different questions.

Reliability without measurement is just hope. SLIs, SLOs, and SLAs turn reliability into a concrete, measurable engineering discipline. They answer three questions: What are we measuring? What target are we committing to? And what happens when we miss? The error budget framework then gives you a rational mechanism for deciding when to ship features versus when to focus on reliability — ending the eternal argument between product and engineering.

Not all metrics make good SLIs. A good SLI directly measures what the user experiences — not internal system health metrics.

Example: SLO = 99.9% over 30 days. Error budget = 0.1% × 43,200 minutes = 43.2 minutes of allowed downtime. Every incident consumes from this budget. When the budget is exhausted: feature freeze, only reliability work until budget regenerates. This is the mechanism Google uses to balance innovation speed with system stability.

Incidents are not a sign of failure — they are inevitable in complex systems. The difference between teams that recover in minutes versus hours is not talent — it is preparation. Runbooks written when calm, severity definitions agreed upon before the fire, escalation paths that don't require remembering who is on call. Incident response is a practiced discipline, not an ad-hoc panic reaction.

An on-call rotation that pages engineers every night is not an on-call rotation — it is a burnout program that destroys teams. On-call health is a leading indicator of engineering retention. Design for sustainability from day one.