Architecture
A zero trust security architecture diagram with device posture checks, MFA identity verification, risk-based policy decisions, short-lived JWT tokens, micro-segmentation, mTLS encryption, least-privilege access enforcement, and continuous monitoring. This template models the 'never trust, always verify' security paradigm where every request is authenticated and authorized regardless of network location. Essential for security architects implementing modern zero-trust frameworks in cloud-native environments.
User { # User / Device
n1: circle label:"Access Request"
n2: rectangle label:"Device Posture Check"
n3: rectangle label:"Identity Verification (MFA)"
n4: rectangle label:"Receive Access Decision"
n5: circle label:"Access Granted or Denied"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Device Compliant"]
n3.handle(bottom) -> PolicyEngine.n6.handle(top) [label="Authenticate"]
n4.handle(right) -> n5.handle(left)
}
PolicyEngine { # Policy Decision Point
n6: rectangle label:"Evaluate Identity Context"
n7: rectangle label:"Check Risk Score"
n8: diamond label:"Trust Level Sufficient?"
n9: rectangle label:"Issue Short-Lived Token"
n10: rectangle label:"Deny and Log"
n11: rectangle label:"Step-Up Authentication"
n6.handle(right) -> n7.handle(left) [label="Context"]
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Trusted"]
n8.handle(bottom) -> n10.handle(top) [label="Denied"]
n8.handle(left) -> n11.handle(right) [label="Elevated"]
n9.handle(bottom) -> Enforcement.n12.handle(top) [label="JWT (5 min TTL)"]
n10.handle(top) -> User.n4.handle(bottom) [label="403"]
n11.handle(top) -> User.n3.handle(bottom) [label="Re-Verify"]
}
Enforcement { # Policy Enforcement Points
n12: rectangle label:"Micro-Segmentation Gateway"
n13: rectangle label:"Encrypt All Traffic (mTLS)"
n14: rectangle label:"Least-Privilege Access"
n15: rectangle label:"Continuous Monitoring"
n12.handle(right) -> n13.handle(left) [label="Segment"]
n13.handle(right) -> n14.handle(left) [label="Encrypted"]
n14.handle(bottom) -> Resources.n16.handle(top) [label="Scoped Access"]
n15.handle(top) -> PolicyEngine.n7.handle(bottom) [label="Risk Signal"]
}
Resources { # Protected Resources
n16: rectangle label:"Application Service"
n17: rectangle label:"Database"
n18: rectangle label:"API Endpoint"
n19: rectangle label:"Audit Log"
n16.handle(right) -> n17.handle(left) [label="Query"]
n16.handle(right) -> n18.handle(left) [label="Call"]
n16.handle(bottom) -> n19.handle(top) [label="Log Access"]
n16.handle(top) -> User.n4.handle(bottom) [label="Response"]
}
Traditional perimeter-based security assumes everything inside the network is trusted—a dangerous assumption when attackers can breach the perimeter or insiders can be compromised. Zero trust verifies every request regardless of network location, using device posture, identity, and risk signals to make continuous access decisions.
VPN-based perimeter security is simpler but assumes internal trust. Identity-aware proxies (BeyondCorp) implement zero trust at the network level. This template shows the complete zero trust architecture from device to resource.
| Template Name | Zero Trust Security Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.
Architecture
A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.