The architectural choice
Every policy design must decide where rules are evaluated. A centralized model sends each decision to a shared service. A distributed model places decision logic next to each application or gateway. Hybrid designs author and approve centrally but evaluate locally. The choice shapes consistency, speed, resilience and the effort needed to operate the system.
Centralized enforcement
Central evaluation gives one place to update rules, one place to log decisions and a single source of truth. A change takes effect everywhere at once, which makes emergency changes simple. The costs are latency for every call, a shared dependency whose outage affects many systems and the need to scale the service for the busiest consumer.
This model suits low-volume, high-sensitivity decisions such as approving a privileged action or a large transaction, where an extra network call is acceptable.
Distributed enforcement
Local evaluation keeps decisions fast and lets applications continue during a control plane outage. It scales naturally with the number of applications. The costs are distribution and drift: each copy of policy must be delivered, versioned and verified. Two services may briefly enforce different versions, and decision logs must be gathered from many places.
This model suits high-volume paths such as API gateways, service meshes and data access layers, where milliseconds count.
Comparison at a glance
- Consistency: central is strongest, distributed depends on distribution speed.
- Latency: distributed is lower, central adds a network hop.
- Resilience: distributed tolerates control plane loss, central needs high availability.
- Audit: central is simpler, distributed needs log aggregation.
- Operations: central scales one service, distributed manages many agents.
A hybrid pattern that works
A common pattern is to author and approve policy in a central repository, publish signed bundles and let each enforcement point pull the latest bundle and evaluate locally. Decision logs stream back to a central store. Enforcement points report the version they are running, so the control plane can see which are stale. Keep a small set of the most sensitive decisions on a central path where freshness matters more than speed.
How to decide
Classify decisions by volume, sensitivity and tolerance for stale rules. Place high-volume, moderate-risk decisions locally and low-volume, high-risk decisions centrally. Define the maximum acceptable policy age for each class, and alert when any enforcement point exceeds it. Revisit the split annually, because traffic patterns and risk tolerance change.
Signals that you chose wrong
Teams using a central service often discover the problem as latency complaints or an outage that spreads across unrelated applications. Teams using local evaluation often discover it as audit gaps, with no one able to say which version of a rule was running last month. Both are fixable, but they are easier to avoid by writing down the maximum acceptable policy age and the maximum acceptable decision latency before choosing.
If either limit is routinely exceeded, adjust the split rather than adding exceptions, since exceptions to the architecture become the next incident.
Cost and staffing considerations
Central services concentrate cost in a few highly available components and a small expert team. Distributed designs spread cost across every application team that must update, monitor and troubleshoot local agents. Estimate both the infrastructure bill and the staff time before choosing, and revisit the estimate after the first six months of operation, when real maintenance effort becomes visible.
