Architecture Governance Patterns: Distributed Locks and Sidecars

Architecture governance becomes friction if it only relies on meetings and reviews. A better approach is to turn repeated problems into patterns with clear boundaries.

Core Concepts

Distributed locks coordinate multiple nodes competing for one resource. The sidecar pattern places cross-cutting capabilities such as logging, proxying, auth, or observability next to the main process.

flowchart TD
    A["Governance problem"] --> B{Resource contention?}
    B -->|Yes| C["Distributed lock"]
    B -->|No| D{Cross-cutting concern?}
    D -->|Yes| E["Sidecar"]
    D -->|No| F["Library / platform / design constraint"]

Engineering Scenario

A distributed lock can prevent duplicated scheduled jobs in multi-instance deployments. A sidecar can keep communication and observability concerns outside business code.

Common Mistakes

• Using locks to hide a wrong domain model.
• Putting too much behavior into sidecars.
• Naming a pattern without providing templates, monitoring, and exit criteria.

Best Practices

• Document when each pattern should and should not be used.
• Provide copyable examples and defaults.
• Monitor lock waits, timeouts, and sidecar health.
• Update governance rules through incident reviews.