Enterprise Backend Checklist

Security & Authentication

Required

Authentication System
Implementation Questions:
- What authentication protocols are supported (JWT, OAuth 2.0, OpenID Connect, SAML)?
- How do you handle token lifecycle management (generation, validation, refresh, revocation)?
- What security measures prevent token theft and replay attacks?
- How do you implement secure password policies and account lockout mechanisms?
- What multi-factor authentication options are available?
- How do you handle authentication across microservices and distributed systems?
Key Considerations:
- Use short-lived access tokens with secure refresh token rotation
- Implement proper token storage (httpOnly cookies, secure storage)
- Support multiple authentication providers and SSO integration
- Log authentication events for security monitoring and compliance
Red Flags:
- Long-lived tokens without proper rotation mechanisms
- Storing tokens in localStorage or insecure client-side storage
- No account lockout or brute force protection
- Authentication credentials transmitted over unencrypted connections
Authorization Framework
Implementation Questions:
- What authorization model is implemented (RBAC, ABAC, or hybrid approach)?
- How are permissions and roles defined and managed?
- What is the process for granting and revoking access rights?
- How do you handle complex authorization scenarios (hierarchical roles, conditional access)?
- What audit trail exists for authorization decisions and changes?
- How is authorization enforced consistently across all API endpoints?
Key Considerations:
- Implement principle of least privilege with default deny policies
- Use centralized policy decision points for consistent authorization
- Support fine-grained resource-level permissions
- Implement permission caching with proper invalidation strategies
Red Flags:
- Authorization logic scattered throughout the codebase
- Over-privileged default roles or permissions
- No regular access reviews or permission audits
- Authorization bypass vulnerabilities in API endpoints
Data Encryption
Implementation Questions:
- What encryption algorithms are used for data at rest (AES-256, ChaCha20-Poly1305)?
- How are encryption keys generated, stored, and rotated securely?
- What TLS versions and cipher suites are enforced for data in transit?
- How do you handle encryption for database fields containing PII or sensitive data?
- What key management systems (HSM, KMS) are integrated for enterprise key lifecycle?
- How do you ensure encrypted data remains accessible during key rotation?
Key Considerations:
- Use hardware security modules (HSM) or cloud KMS for key management
- Implement envelope encryption for large datasets and database encryption
- Ensure proper certificate management and automated TLS certificate renewal
- Consider field-level encryption for highly sensitive data elements
Red Flags:
- Storing encryption keys alongside encrypted data or in application code
- Using deprecated encryption algorithms or weak key sizes
- No automated key rotation or manual key management processes
- Allowing unencrypted communication channels for sensitive data transfer
Security Headers
Implementation Questions:
- What Content Security Policy (CSP) directives are configured to prevent XSS attacks?
- How are CORS policies configured to allow legitimate cross-origin requests?
- What HTTP Strict Transport Security (HSTS) settings enforce HTTPS usage?
- How do you handle security headers for different environments (dev, staging, prod)?
- What X-Frame-Options and X-Content-Type-Options headers are set?
- How do you validate and test security header effectiveness?
Key Considerations:
- Implement strict CSP policies with nonce-based or hash-based script execution
- Configure HSTS with appropriate max-age and includeSubDomains directives
- Use restrictive CORS policies that only allow necessary origins and methods
- Set security headers at the web server or load balancer level for consistency
Red Flags:
- Overly permissive CORS policies allowing wildcard origins in production
- Missing or weak Content Security Policy allowing unsafe-inline scripts
- No HSTS header or insufficient max-age values for HTTPS enforcement
- Security headers only set in application code rather than infrastructure level
Input Validation
Implementation Questions:
- What input validation frameworks or libraries are used for different data types?
- How do you handle validation for JSON, XML, and file upload inputs?
- What sanitization techniques prevent SQL injection, XSS, and LDAP injection?
- How are parameterized queries and prepared statements enforced?
- What size limits and rate limiting prevent DoS through large payloads?
- How do you validate and sanitize data from external APIs and third-party sources?
Key Considerations:
- Implement allow-list validation rather than block-list approaches
- Use ORM frameworks with built-in SQL injection protection
- Validate data at multiple layers (client, API gateway, application, database)
- Implement context-aware output encoding for different rendering contexts
Red Flags:
- Using string concatenation for database queries instead of parameterized statements
- Client-side validation as the only line of defense against malicious input
- No size limits on file uploads or request payloads
- Trusting data from external sources without proper validation and sanitization

Suggested

MFA Implementation
Implementation Questions:
- What MFA methods are supported (TOTP, SMS, push notifications, hardware keys)?
- How do you handle MFA enrollment and backup recovery codes?
- What policies determine when MFA is required (high-risk operations, new devices)?
- How do you integrate with enterprise MFA providers and identity systems?
- What fallback mechanisms exist when primary MFA methods are unavailable?
- How do you prevent MFA bypass attacks and session hijacking?
Key Considerations:
- Support multiple MFA methods to accommodate different user preferences and security levels
- Implement risk-based authentication to require MFA for suspicious activities
- Provide secure backup codes and admin override capabilities for account recovery
- Integrate with hardware security keys (FIDO2/WebAuthn) for phishing-resistant authentication
Red Flags:
- Relying solely on SMS-based MFA which is vulnerable to SIM swapping
- No backup authentication methods leading to account lockout scenarios
- MFA requirements that can be easily bypassed through alternative login paths
- Storing MFA secrets or backup codes in plaintext or weakly encrypted format
Security Monitoring
Implementation Questions:
- What security monitoring tools detect anomalous behavior and attack patterns?
- How do you monitor for indicators of compromise (IoCs) and threat intelligence feeds?
- What automated response capabilities block or mitigate detected threats?
- How do you correlate security events across multiple systems and log sources?
- What alerting mechanisms notify security teams of high-priority incidents?
- How do you reduce false positives while maintaining security coverage?
Key Considerations:
- Implement SIEM solutions with automated threat detection and correlation
- Use behavioral analysis to detect unusual access patterns and insider threats
- Configure automated blocking for known malicious IPs and attack signatures
- Integrate with threat intelligence feeds for up-to-date attack pattern recognition
Red Flags:
- High false positive rates leading to alert fatigue and ignored warnings
- No automated response capabilities requiring manual intervention for all threats
- Security monitoring tools that don't integrate with existing infrastructure
- Long detection and response times allowing attackers to establish persistence
Secrets Management Integration
Implementation Questions:
- What secrets management platform handles credentials, API keys, and certificates?
- How do applications authenticate to the secrets management system securely?
- What rotation policies ensure regular updates of sensitive credentials?
- How do you handle secrets injection into containerized and serverless environments?
- What audit logging tracks secrets access and usage patterns?
- How do you manage secrets across different environments (dev, staging, prod)?
Key Considerations:
- Use cloud-native secrets management services (AWS Secrets Manager, Azure Key Vault)
- Implement automated secret rotation with zero-downtime updates
- Use workload identity or service principals for application authentication
- Encrypt secrets at rest and in transit with proper access controls
Red Flags:
- Hardcoded secrets, passwords, or API keys in source code or configuration files
- Manual secret rotation processes prone to human error and delays
- Sharing secrets through insecure channels (email, chat, plain text files)
- No audit trail for secret access or modification activities
Comprehensive Audit Logging
Implementation Questions:
- What security events and user activities are logged (authentication, authorization, data access)?
- How do you ensure log integrity and prevent tampering or deletion?
- What log retention policies meet compliance requirements and investigation needs?
- How are logs centralized, indexed, and made searchable for incident response?
- What alerting rules detect suspicious patterns in audit logs?
- How do you balance comprehensive logging with storage costs and performance impact?
Key Considerations:
- Implement structured logging with consistent formats and correlation IDs
- Use immutable log storage and cryptographic checksums for integrity
- Include contextual information (user ID, IP address, request ID, timestamp)
- Implement log aggregation and SIEM integration for real-time analysis
Red Flags:
- Logging sensitive data (passwords, credit card numbers, personal information) in plaintext
- No protection against log tampering or unauthorized access to audit trails
- Insufficient log retention periods that don't meet regulatory requirements
- Performance degradation due to synchronous logging without proper buffering

API Design

Required

RESTful Standards
Implementation Questions:
- Are HTTP methods used semantically correctly (GET, POST, PUT, DELETE, PATCH)?
- Do API endpoints follow consistent resource naming conventions?
- Are HTTP status codes used appropriately and consistently?
- How do you handle complex operations that don't fit standard CRUD patterns?
- What standards govern request/response body structure and error formats?
- How do you ensure API responses are consistent across all endpoints?
Key Considerations:
- Use nouns for resources and HTTP verbs for actions
- Implement consistent error response formats with proper status codes
- Support standard HTTP headers (Accept, Content-Type, Authorization)
- Follow RESTful principles for nested resources and relationships
Red Flags:
- Using GET requests for operations that modify data
- Inconsistent naming conventions across different endpoints
- Always returning 200 OK regardless of actual operation outcome
- Mixing RPC-style and REST-style patterns without clear rationale
API Documentation
Implementation Questions:
- How is API documentation generated and kept in sync with code changes?
- What interactive documentation tools allow developers to test endpoints?
- How do you document authentication, authorization, and error responses?
- What code examples and SDKs are provided for different programming languages?
- How do you version API documentation alongside API changes?
- What processes ensure documentation accuracy and completeness before releases?
Key Considerations:
- Use OpenAPI 3.0 specifications with automated documentation generation
- Provide interactive API explorers and sandbox environments
- Include comprehensive examples for request/response payloads and error scenarios
- Implement documentation testing to validate examples against actual API behavior
Red Flags:
- Manual documentation maintenance that falls out of sync with code changes
- Missing or incomplete error response documentation
- No interactive testing capabilities in the documentation
- Documentation that doesn't include authentication or authorization requirements
API Versioning
Implementation Questions:
- What versioning scheme is used (semantic versioning, date-based, sequential)?
- How is version information communicated (URL path, headers, query parameters)?
- What backward compatibility guarantees are provided for different version types?
- How long are deprecated API versions supported before removal?
- What migration tools and documentation help clients upgrade to newer versions?
- How do you handle breaking changes and communicate them to API consumers?
Key Considerations:
- Use semantic versioning with clear major.minor.patch conventions
- Implement version negotiation through Accept headers or URL versioning
- Maintain multiple API versions simultaneously with proper routing
- Provide clear deprecation timelines and migration guides for breaking changes
Red Flags:
- Making breaking changes without version increments or proper communication
- No clear deprecation policy or timeline for removing old API versions
- Version proliferation without consolidation or retirement strategies
- Inconsistent versioning schemes across different API endpoints
Rate Limiting
Implementation Questions:
- What rate limiting algorithms are used (token bucket, sliding window, fixed window)?
- How are rate limits configured per user, API key, or endpoint?
- What headers communicate rate limit status and reset times to clients?
- How do you handle burst traffic and temporary rate limit increases?
- What monitoring tracks rate limit violations and potential abuse patterns?
- How do you implement different rate limits for premium vs. free tier users?
Key Considerations:
- Implement distributed rate limiting for horizontally scaled applications
- Use different rate limits for different endpoint types (read vs. write operations)
- Provide clear HTTP status codes (429) and informative error messages
- Consider implementing graceful degradation rather than hard blocking
Red Flags:
- No rate limiting allowing unlimited requests to exhaust system resources
- Rate limits that are too restrictive and impact legitimate user workflows
- Inconsistent rate limiting across different API endpoints
- No monitoring or alerting for rate limit violations and potential abuse

Suggested

GraphQL Support
Implementation Questions:
- What GraphQL schema design patterns handle complex business domains?
- How do you implement authentication and authorization in GraphQL resolvers?
- What query depth limiting and complexity analysis prevent resource exhaustion?
- How do you handle N+1 query problems and implement efficient data loading?
- What caching strategies work effectively with GraphQL's dynamic queries?
- How do you version GraphQL schemas and handle breaking changes?
Key Considerations:
- Use DataLoader patterns to batch and cache database queries efficiently
- Implement query complexity analysis and depth limiting for security
- Design schema with proper field-level authorization and data privacy
- Consider federation for microservices architectures with multiple GraphQL services
Red Flags:
- No query complexity limits allowing resource-exhausting queries
- N+1 query problems causing database performance issues
- Exposing sensitive data without proper field-level authorization
- Poor schema design leading to client-side complexity and over-coupling
Modern API Paradigms (tRPC & GraphQL Federation)
Implementation Questions:
- For full-stack TypeScript projects, have you evaluated tRPC for end-to-end type-safe APIs without a separate schema or codegen step?
- For multi-team GraphQL services, is GraphQL Federation (or a similar supergraph approach) used to compose subgraphs owned by different teams into a single graph?
- How do you decide between REST, GraphQL, gRPC, tRPC, and GraphQL Federation for a given service based on client type, team topology, and performance needs?
- How is authentication and authorization enforced consistently across federated subgraphs or tRPC routers?
- What tooling validates schema compatibility when composing a federated supergraph or evolving tRPC router types?
- How do you document and version APIs built with these newer paradigms for external and internal consumers?
Key Considerations:
- Use tRPC when both client and server are TypeScript and you want compile-time type safety without maintaining a separate API contract
- Use GraphQL Federation when multiple teams own independent GraphQL subgraphs that need to be composed into one graph for clients
- Match the paradigm to the actual constraint (team boundaries, client language diversity, performance) rather than defaulting to REST, GraphQL, or gRPC out of habit
- Keep the choice consistent with existing auth, rate limiting, and observability tooling so new paradigms don't create blind spots
Red Flags:
- Adopting tRPC across polyglot clients where the lack of a language-agnostic contract creates integration friction
- Federating GraphQL subgraphs without a schema registry or composition checks, risking breaking changes at the supergraph level
- Mixing paradigms without a documented rationale, leading to inconsistent client integration patterns
- No consistent authorization enforcement across federated subgraphs, creating gaps at composition boundaries
API Gateway
Implementation Questions:
- What API gateway features handle routing, load balancing, and service discovery?
- How are cross-cutting concerns (authentication, authorization, logging) implemented?
- What request/response transformation capabilities support legacy system integration?
- How do you handle API gateway high availability and disaster recovery?
- What monitoring and analytics capabilities track API usage and performance?
- How do you manage API gateway configuration and deployment across environments?
Key Considerations:
- Implement centralized authentication and authorization policies
- Use circuit breakers and timeout configurations for resilient service communication
- Configure request/response caching and rate limiting at the gateway level
- Implement comprehensive logging and metrics collection for all API traffic
Red Flags:
- API gateway becoming a single point of failure without proper redundancy
- Performance bottlenecks due to inadequate gateway scaling or configuration
- Complex business logic implemented in the gateway rather than services
- Inconsistent security policies between gateway and individual services
API Analytics
Implementation Questions:
- What metrics are tracked (request volume, response times, error rates, throughput)?
- How do you segment analytics by user, endpoint, geographic region, or client type?
- What dashboards and reporting provide insights into API usage patterns?
- How do you identify and alert on unusual traffic patterns or anomalies?
- What tools track API adoption rates and feature usage by different client applications?
- How do you measure and optimize API performance and user satisfaction?
Key Considerations:
- Implement real-time monitoring with customizable alerting thresholds
- Use distributed tracing to track requests across microservices
- Collect user feedback and satisfaction metrics alongside technical metrics
- Implement cost tracking for different API consumers and usage patterns
Red Flags:
- No visibility into API performance degradation or error patterns
- Metrics collection that impacts API performance or adds significant latency
- Analytics data stored without proper privacy controls or access restrictions
- No correlation between technical metrics and business outcomes

AI/LLM Backend Integration

Required

RAG Pipeline & Vector Database Integration
Implementation Questions:
- How is the retrieval step (embedding generation, similarity search, re-ranking) orchestrated separately from the generation step so each can be scaled, monitored, and failed over independently?
- What vector database is used, and how is it deployed, backed up, and access-controlled (network policies, service accounts, per-tenant namespaces/collections)?
- How do you keep embeddings in sync with source-of-truth data as documents are created, updated, or deleted?
- What access control ensures a query against the vector store only returns chunks the requesting user or tenant is authorized to see?
- How do you monitor retrieval quality and latency separately from generation quality?
- How do you handle embedding model versioning and re-indexing when the embedding model changes?
Key Considerations:
- Treat the vector database as a first-class data store requiring the same authentication, authorization, encryption, and backup discipline as your primary database
- Enforce document-level authorization at retrieval time, not just at the API gateway, so retrieval can't leak data across tenants
- Decouple retrieval and generation services so each can be scaled and rate-limited independently
- Cache embeddings and retrieval results where freshness requirements allow, to reduce vector database load and cost
Red Flags:
- Vector database exposed without authentication or with a single shared collection across all tenants
- No process for keeping embeddings in sync with deletions, allowing retrieval of stale or removed data
- Retrieval results returned without re-checking the requesting user's authorization for each retrieved chunk
- RAG pipeline steps tightly coupled into a single synchronous call with no independent scaling or observability
Prompt Injection Defense at the API Boundary
Implementation Questions:
- What input sanitization runs on user-supplied text and retrieved/RAG content before it reaches the model (delimiter injection, instruction-override attempts)?
- How do you validate and constrain model output before it is returned to clients or used to trigger downstream actions?
- How do you distinguish trusted system/developer instructions from untrusted user or retrieved content in the prompt structure?
- What monitoring detects anomalous prompts or outputs consistent with injection or jailbreak attempts?
- How do you handle model output that contains executable content (code, SQL, shell commands) before it is executed or rendered?
- How is this backend-layer defense coordinated with model-level governance controls?
Key Considerations:
- Sanitize and clearly delimit untrusted content (user input, retrieved documents) separately from trusted system instructions
- Validate structured output against a schema before consuming it programmatically; never directly execute model-generated code or commands without review
- Apply output filtering for sensitive data leakage (PII, secrets) in addition to input filtering
- For model-level red-teaming, jailbreak testing, and generative-AI governance, see the enterprise-aiml-checklist
Red Flags:
- User input or retrieved content concatenated directly into prompts with no sanitization or delimiting
- Model output passed directly to a shell, SQL query, or eval() without validation
- No logging or monitoring of prompts/outputs to detect injection attempts
- Treating prompt-injection defense as solely a model-level concern with no backend-side controls

Suggested

LLM API Rate Limiting & Cost Control
Implementation Questions:
- How are LLM API calls rate-limited per user, tenant, or API key, separate from general API rate limiting?
- What token-based budgets or quotas prevent runaway generation costs from a single request or user?
- How do you track and attribute LLM spend by feature, team, or customer for cost accounting?
- What fallback behavior (smaller model, cached response, graceful error) applies when quotas or provider rate limits are hit?
- How do you handle streaming responses and long-running generations in your rate-limiting and timeout strategy?
- What alerting exists for unexpected spikes in LLM API cost or usage?
Key Considerations:
- Rate-limit and budget by token count/cost, not just request count, since LLM cost scales with input and output tokens
- Implement per-tenant and per-feature cost attribution to catch runaway usage early
- Set hard timeouts and max-token limits on generation calls to bound worst-case latency and cost
- Build in graceful degradation (cached answers, smaller/cheaper models) when limits are reached rather than hard failures
Red Flags:
- No token-level budget, allowing a single request to generate unbounded output and cost
- LLM API keys shared across all tenants/features with no per-tenant usage attribution
- No alerting when LLM spend spikes unexpectedly
- Rate limiting applied only at the general API gateway without LLM-specific token/cost awareness
AI Agent & Tool-Calling Security
Implementation Questions:
- What backend actions/tools can an AI agent invoke, and is that set explicitly scoped and allow-listed rather than open-ended?
- How do you enforce the same authentication/authorization checks on agent-invoked actions as on direct user-invoked actions?
- What approval or confirmation step is required before an agent executes a high-risk or irreversible action (payments, deletions, external communications)?
- How do you log and audit every tool call an agent makes, including the context that triggered it?
- How do you prevent an agent from chaining tool calls in ways that escalate privilege or bypass business rules?
- How do you test agent behavior against adversarial prompts designed to trigger unintended tool calls?
Key Considerations:
- Scope agent tool access with the same least-privilege principle used for human accounts and service accounts
- Require the backend to independently validate and authorize every agent-invoked action, never trusting the model's own judgment as the sole gate
- Gate irreversible or high-impact actions behind explicit confirmation or human-in-the-loop approval
- Audit-log tool calls with enough context to reconstruct why the agent took an action
Red Flags:
- Agents granted broad or unscoped API/database access "to be flexible"
- Tool-calling actions executed without re-validating authorization at the backend, trusting the model's function-call output directly
- No audit trail linking an agent's tool calls back to the triggering request or user
- High-risk actions (payments, deletions, data exports) executable by an agent without human confirmation

Database Management

Required

Data Model Design
Implementation Questions:
- What normalization level balances data integrity with query performance?
- How are indexes designed to support query patterns and avoid over-indexing?
- What partitioning strategies handle large datasets and improve query performance?
- How do you model complex relationships while maintaining referential integrity?
- What data types and constraints ensure data quality and consistency?
- How do you handle schema evolution and migration in production systems?
Key Considerations:
- Design schemas based on query patterns and access frequencies
- Use composite indexes for multi-column query optimization
- Implement proper foreign key constraints and data validation rules
- Consider denormalization for read-heavy workloads and analytical queries
Red Flags:
- Over-normalized schemas causing excessive JOIN operations and poor performance
- Missing indexes on frequently queried columns leading to full table scans
- No data modeling documentation or schema change management process
- Circular dependencies or poorly designed relationships causing data integrity issues
Database Security
Implementation Questions:
- What authentication mechanisms secure database connections (certificate-based, IAM roles)?
- How are database credentials rotated and managed securely?
- What encryption methods protect data at rest and in transit?
- How do you implement row-level security and column-level access controls?
- What database audit logging captures access patterns and security events?
- How do you secure database backups and prevent unauthorized access?
Key Considerations:
- Use connection pooling with encrypted connections and certificate validation
- Implement database-level encryption with proper key management integration
- Configure role-based access control with principle of least privilege
- Enable comprehensive audit logging without impacting performance
Red Flags:
- Database credentials hardcoded in application code or configuration files
- Unencrypted database connections or data transmission
- Overly permissive database user privileges allowing unnecessary access
- No monitoring for unusual database access patterns or privilege escalation
Backup Strategy
Implementation Questions:
- What backup strategies handle different data types (full, incremental, differential)?
- How frequently are backups performed and what is the recovery point objective (RPO)?
- What automated testing validates backup integrity and restore procedures?
- How are backups encrypted and stored securely across multiple locations?
- What disaster recovery procedures handle different failure scenarios?
- How long are backups retained and what compliance requirements apply?
Key Considerations:
- Implement automated backup scheduling with monitoring and alerting
- Store backups in geographically distributed locations for disaster recovery
- Use incremental backups to minimize storage costs and backup windows
- Regularly test restore procedures in isolated environments
Red Flags:
- No automated backup validation or restore testing procedures
- Backup files stored in the same location as primary data
- Long backup windows impacting application performance
- No monitoring or alerting for backup failures or corruption
Migration Strategy
Implementation Questions:
- What migration frameworks manage schema changes and rollback procedures?
- How do you handle zero-downtime migrations for production systems?
- What testing procedures validate migrations against production-like data?
- How are migration dependencies and sequencing managed across multiple databases?
- What rollback strategies handle failed migrations without data loss?
- How do you coordinate schema changes with application deployments?
Key Considerations:
- Use idempotent migration scripts that can be safely re-executed
- Implement backward-compatible changes and feature flags for complex migrations
- Version control all schema changes with proper code review processes
- Test migrations on production-sized datasets in staging environments
Red Flags:
- Manual schema changes without version control or documentation
- Migration scripts that cannot be rolled back safely
- No testing of migrations on production-sized datasets
- Schema changes deployed without coordinating with application changes

Suggested

Database Replication
Implementation Questions:
- What replication topology supports read scaling and high availability requirements?
- How do you handle replication lag and ensure data consistency?
- What automated failover mechanisms promote replicas during outages?
- How do you route read queries to replicas while maintaining data freshness?
- What monitoring detects replication issues and failover events?
- How do you handle split-brain scenarios and data conflicts?
Key Considerations:
- Configure multiple read replicas across different availability zones
- Implement connection pooling that routes queries based on read/write requirements
- Use synchronous replication for critical data and asynchronous for performance
- Monitor replication lag and implement alerts for threshold breaches
Red Flags:
- High replication lag causing data consistency issues for applications
- No automated failover mechanisms requiring manual intervention
- Single replica configuration without geographic distribution
- Application queries that don't handle replica unavailability gracefully
Query Optimization
Implementation Questions:
- What tools monitor query performance and identify slow-running queries?
- How do you analyze query execution plans and optimize inefficient operations?
- What indexing strategies improve query performance without excessive overhead?
- How do you handle query optimization for different workload patterns?
- What connection pooling and query caching mechanisms reduce database load?
- How do you monitor database resource utilization and capacity planning?
Key Considerations:
- Use query performance monitoring tools with automated slow query detection
- Implement query result caching for frequently accessed data
- Optimize queries using proper indexes, query rewriting, and execution plan analysis
- Configure connection pooling to manage database connections efficiently
Red Flags:
- No monitoring of query performance or slow query identification
- Queries with full table scans on large datasets
- Excessive connection overhead without proper pooling mechanisms
- No capacity planning for database growth and performance scaling
Data Archival
Implementation Questions:
- What policies determine data archival criteria and retention periods?
- How do you implement automated data lifecycle management?
- What archival storage solutions balance cost and accessibility requirements?
- How do you handle data dependencies when archiving related records?
- What compliance requirements govern data retention and deletion?
- How do you restore archived data when needed for analysis or legal requirements?
Key Considerations:
- Implement automated archival based on data age, access patterns, and business rules
- Use tiered storage solutions with different cost and performance characteristics
- Maintain data referential integrity during archival and cleanup operations
- Document data retention policies and ensure compliance with regulations
Red Flags:
- No data retention policies leading to unlimited storage growth
- Manual data cleanup processes prone to errors and inconsistencies
- Archival processes that break data relationships or referential integrity
- No mechanism to restore archived data when required for business or legal needs

Performance & Scalability

Required

Caching Strategy
Implementation Questions:
- What caching layers are implemented (browser, CDN, reverse proxy, application, database)?
- How do you determine what data to cache and for how long?
- What cache invalidation strategies prevent stale data issues?
- How do you handle cache warming and cold start scenarios?
- What mechanisms exist for cache coherency across distributed systems?
- How do you monitor cache hit rates and performance impact?
Key Considerations:
- Implement appropriate cache eviction policies (LRU, LFU, TTL-based)
- Use cache-aside, write-through, or write-behind patterns as appropriate
- Consider distributed caching for horizontally scaled applications
- Implement cache fallback strategies for when cache services are unavailable
Red Flags:
- Caching critical data without proper invalidation strategies
- Cache stampede problems during high traffic or cache expiration
- No monitoring of cache performance or hit/miss ratios
- Caching user-specific or sensitive data in shared cache layers
Load Balancing
Implementation Questions:
- What load balancing algorithms distribute traffic (round-robin, least connections, weighted)?
- How do you handle session affinity and stateful applications?
- What health checks ensure traffic is only routed to healthy instances?
- How do you implement SSL termination and certificate management?
- What geographic load balancing distributes traffic across regions?
- How do you handle load balancer failover and high availability?
Key Considerations:
- Use application load balancers with sophisticated routing rules
- Implement proper health checks with configurable thresholds and intervals
- Configure SSL/TLS termination with modern cipher suites and protocols
- Use multiple load balancer instances across availability zones for redundancy
Red Flags:
- Single load balancer instance creating a single point of failure
- No health checks leading to traffic routing to unhealthy instances
- Session affinity causing uneven load distribution and scaling issues
- Load balancer configuration that doesn't properly handle SSL/TLS termination
Horizontal Scaling
Implementation Questions:
- How do you ensure services are stateless and can be scaled horizontally?
- What external storage solutions handle shared state (cache, database, message queues)?
- How do you partition workloads to enable independent scaling?
- What service discovery mechanisms handle dynamic service instances?
- How do you manage configuration and secrets across scaled instances?
- What patterns handle distributed transactions and data consistency?
Key Considerations:
- Design services without local state storage or in-memory sessions
- Use externalized configuration and centralized secret management
- Implement idempotent operations that can be safely retried
- Use event-driven architecture to decouple services and enable scaling
Red Flags:
- Services that store state locally preventing horizontal scaling
- Tight coupling between services causing scaling bottlenecks
- No service discovery mechanism for dynamically scaled instances
- Shared databases or resources that become bottlenecks during scaling
Performance Monitoring
Implementation Questions:
- What key performance indicators (KPIs) are tracked (response time, throughput, error rate)?
- How do you implement distributed tracing across microservices?
- What alerting rules trigger notifications for performance degradation?
- How do you correlate performance metrics with business impact?
- What dashboards provide real-time visibility into system performance?
- How do you perform capacity planning based on performance trends?
Key Considerations:
- Implement comprehensive observability with metrics, logs, and traces
- Use Service Level Objectives (SLOs) to define acceptable performance thresholds
- Configure alerting with appropriate escalation and on-call procedures
- Implement performance budgets and automated performance testing
Red Flags:
- No end-to-end performance visibility across distributed systems
- Alert fatigue from too many false positives or low-priority notifications
- Performance monitoring that adds significant overhead to applications
- No correlation between technical performance metrics and user experience

Suggested

CDN Integration
Implementation Questions:
- What content types are cached at CDN edge locations (static assets, API responses)?
- How do you configure cache invalidation and purging strategies?
- What geographic distribution ensures optimal content delivery performance?
- How do you handle dynamic content and personalization with CDN caching?
- What security features protect against DDoS attacks and bot traffic?
- How do you monitor CDN performance and cache hit rates?
Key Considerations:
- Use appropriate cache headers and TTL settings for different content types
- Implement cache warming strategies for high-traffic content
- Configure origin failover and multiple origin server support
- Use edge compute capabilities for dynamic content processing
Red Flags:
- No cache invalidation strategy leading to stale content delivery
- Caching dynamic or user-specific content inappropriately
- Poor geographic coverage resulting in high latency for some users
- No monitoring of CDN performance or origin server health
Auto-Scaling
Implementation Questions:
- What metrics trigger scaling decisions (CPU, memory, request count, custom metrics)?
- How do you configure scaling thresholds and cooldown periods?
- What scaling policies handle different traffic patterns (gradual vs. spike)?
- How do you implement predictive scaling based on historical patterns?
- What safeguards prevent excessive scaling costs or resource waste?
- How do you handle scaling coordination across multiple services?
Key Considerations:
- Use multiple metrics for scaling decisions to avoid false triggers
- Implement proper cooldown periods to prevent scaling oscillation
- Configure minimum and maximum instance limits for cost control
- Use predictive scaling for known traffic patterns and events
Red Flags:
- Scaling based on single metrics causing inappropriate scaling decisions
- No maximum limits leading to unexpected cost increases
- Scaling oscillation due to improper cooldown periods
- Auto-scaling that doesn't account for application startup time
Performance Testing
Implementation Questions:
- What load testing tools and scenarios validate system capacity and performance?
- How do you simulate realistic user behavior and traffic patterns?
- What performance benchmarks and SLIs are measured during testing?
- How do you identify performance bottlenecks and capacity limits?
- What automated performance testing integrates with CI/CD pipelines?
- How do you conduct chaos testing and failure scenario validation?
Key Considerations:
- Implement continuous performance testing in staging environments
- Use production-like data volumes and traffic patterns for accurate testing
- Test different failure scenarios including dependency failures
- Establish performance budgets and automated regression detection
Red Flags:
- Performance testing only during major releases rather than continuously
- Load tests that don't reflect realistic user behavior or data volumes
- No automated performance regression detection in CI/CD pipelines
- Testing environments that don't match production configuration

Microservices Architecture

Required

Service Discovery
Implementation Questions:
- What service discovery mechanisms locate and communicate with service instances?
- How do services register themselves and update their health status?
- What load balancing integrates with service discovery for traffic routing?
- How do you handle service discovery failures and fallback mechanisms?
- What DNS or API-based discovery patterns work best for your architecture?
- How do you manage service discovery across multiple environments and regions?
Key Considerations:
- Use health check endpoints that accurately reflect service readiness
- Implement graceful service registration and deregistration during deployments
- Configure appropriate TTL values for service discovery caching
- Use service mesh or API gateway integration for centralized discovery
Red Flags:
- Hard-coded service endpoints preventing dynamic scaling and deployment
- No health checks leading to traffic routing to unhealthy service instances
- Service discovery single point of failure without redundancy
- Stale service registration causing connection failures and timeouts
Circuit Breaking
Implementation Questions:
- What failure thresholds trigger circuit breaker activation?
- How do you configure different circuit breaker states (closed, open, half-open)?
- What fallback mechanisms provide graceful degradation during failures?
- How do you implement timeouts and retry policies for external dependencies?
- What monitoring tracks circuit breaker state changes and failure patterns?
- How do you test circuit breaker behavior and recovery scenarios?
Key Considerations:
- Configure circuit breakers for all external service dependencies
- Implement different timeout values based on operation criticality
- Use exponential backoff for retry mechanisms to avoid cascading failures
- Provide meaningful fallback responses rather than generic error messages
Red Flags:
- No circuit breakers allowing cascading failures across services
- Circuit breaker thresholds that are too sensitive or too lenient
- No fallback mechanisms causing complete feature unavailability
- Infinite or excessive retry attempts overwhelming failing services
API Gateway
Implementation Questions:
- How does the API gateway handle request routing to appropriate microservices?
- What cross-cutting concerns are implemented (authentication, rate limiting, logging)?
- How do you handle API gateway versioning and backward compatibility?
- What request/response transformation capabilities support legacy integration?
- How do you implement API gateway high availability and disaster recovery?
- What security policies prevent unauthorized access and API abuse?
Key Considerations:
- Implement centralized authentication and authorization at the gateway level
- Use request/response caching and compression for performance optimization
- Configure proper error handling and circuit breaker integration
- Implement comprehensive logging and monitoring for all API traffic
Red Flags:
- API gateway becoming a monolithic bottleneck with complex business logic
- No redundancy or failover mechanisms for the API gateway
- Inconsistent security policies between gateway and individual services
- Poor performance due to inadequate caching or resource allocation
Service Communication
Implementation Questions:
- What communication patterns are used (synchronous REST, asynchronous messaging, gRPC)?
- How do you handle service-to-service authentication and authorization?
- What message formats and serialization protocols ensure interoperability?
- How do you implement distributed transaction patterns (Saga, Two-Phase Commit)?
- What event-driven patterns decouple services and improve scalability?
- How do you handle API contract versioning and breaking changes?
Key Considerations:
- Use asynchronous messaging for loose coupling and better resilience
- Implement service contracts with schema validation and compatibility testing
- Use correlation IDs for distributed tracing and debugging
- Configure appropriate timeouts and retry policies for different communication types
Red Flags:
- Tight coupling between services through direct database access
- No standardized communication protocols causing integration complexity
- Synchronous communication chains creating cascading failure risks
- No contract testing leading to runtime integration failures

Suggested

Service Mesh
Implementation Questions:
- What service mesh features provide value (traffic management, security, observability)?
- How do you implement mTLS for service-to-service communication?
- What traffic routing and load balancing capabilities are needed?
- How do you handle service mesh configuration and policy management?
- What observability features provide insights into service communication?
- How do you migrate existing services to service mesh gradually?
Key Considerations:
- Evaluate service mesh complexity vs. benefits for your architecture
- Implement gradual rollout with canary deployments and traffic splitting
- Use service mesh for security policies and zero-trust networking
- Leverage observability features for distributed tracing and metrics
Red Flags:
- Service mesh adding significant complexity without clear benefits
- Poor performance due to excessive proxy overhead or misconfiguration
- No clear migration strategy causing partial or inconsistent adoption
- Service mesh configuration drift causing security or reliability issues
Event Sourcing
Implementation Questions:
- What business domains benefit from event sourcing (audit trails, complex workflows)?
- How do you design events for immutability and future schema evolution?
- What event storage solutions handle high throughput and long-term retention?
- How do you implement event replay and temporal queries?
- What CQRS patterns separate command and query responsibilities?
- How do you handle event versioning and backward compatibility?
Key Considerations:
- Use event sourcing for domains requiring complete audit trails
- Implement event snapshotting for performance optimization
- Design events as immutable facts rather than state changes
- Consider eventual consistency implications for read models
Red Flags:
- Applying event sourcing to simple CRUD operations without clear benefits
- No event versioning strategy causing compatibility issues
- Poor event design leading to complex event replay scenarios
- Event storage becoming a bottleneck without proper scaling strategy
CQRS Pattern
Implementation Questions:
- What scenarios justify separating command and query responsibilities?
- How do you design command models for business operations and validation?
- What read models optimize query performance for different use cases?
- How do you synchronize data between command and query sides?
- What eventual consistency patterns handle read model updates?
- How do you handle complex queries spanning multiple bounded contexts?
Key Considerations:
- Use CQRS when read and write requirements have different optimization needs
- Implement separate data models optimized for commands vs. queries
- Use event-driven synchronization between command and query sides
- Consider read model denormalization for query performance
Red Flags:
- Implementing CQRS for simple applications without complex query requirements
- No clear separation of command and query responsibilities
- Complex synchronization logic between command and query models
- Read models that become too complex or difficult to maintain

DevOps & CI/CD

Required

Automated Testing
Implementation Questions:
- What testing strategies cover different application layers (unit, integration, e2e)?
- How do you achieve adequate test coverage without excessive maintenance overhead?
- What test data management strategies support consistent and repeatable tests?
- How do you implement contract testing between services and APIs?
- What performance and security testing integrates with your test suite?
- How do you handle test execution parallelization and optimization?
Key Considerations:
- Follow the test pyramid principle with more unit tests than integration tests
- Use test doubles (mocks, stubs) appropriately to isolate units under test
- Implement database rollback strategies for consistent integration test environments
- Use property-based testing for complex business logic validation
Red Flags:
- Low test coverage or tests that don't provide meaningful validation
- Flaky tests that pass/fail intermittently causing pipeline instability
- Slow test execution times impacting developer productivity
- Tests that require manual setup or depend on external services
CI/CD Pipeline
Implementation Questions:
- What CI/CD tools and platforms support your build and deployment processes?
- How do you implement automated quality gates and approval workflows?
- What artifact management and versioning strategies support deployments?
- How do you handle different deployment strategies (blue-green, rolling, canary)?
- What rollback mechanisms handle failed deployments quickly?
- How do you implement progressive delivery and feature flag integration?
Key Considerations:
- Implement pipeline as code with version control and change management
- Use automated security scanning and vulnerability assessment
- Configure different pipelines for different environments with appropriate gates
- Implement comprehensive deployment validation and smoke testing
Red Flags:
- Manual deployment processes prone to human error and inconsistency
- No automated rollback capabilities causing extended downtime
- Pipeline configuration not under version control
- Long deployment times impacting release frequency and agility
Infrastructure as Code
Implementation Questions:
- What Infrastructure as Code (IaC) tools manage your cloud and on-premise resources?
- How do you structure and organize infrastructure code for reusability?
- What state management strategies handle concurrent infrastructure changes?
- How do you implement infrastructure testing and validation?
- What processes govern infrastructure changes and approvals?
- How do you handle secrets and sensitive configuration in IaC?
Key Considerations:
- Use modular infrastructure code with reusable components and modules
- Implement remote state storage with locking for team collaboration
- Use infrastructure testing tools to validate configurations
- Implement proper resource tagging and cost management strategies
Red Flags:
- Manual infrastructure provisioning without documentation or repeatability
- Infrastructure drift due to manual changes outside of IaC
- No infrastructure testing leading to deployment failures
- Hardcoded secrets or sensitive values in infrastructure code
Monitoring & Logging
Implementation Questions:
- What observability strategy covers metrics, logs, and distributed tracing?
- How do you implement structured logging with correlation IDs across services?
- What alerting rules and escalation procedures handle different severity levels?
- How do you implement dashboard and visualization for different stakeholders?
- What log retention and compliance requirements govern your logging strategy?
- How do you handle monitoring and alerting for both infrastructure and applications?
Key Considerations:
- Implement the three pillars of observability: metrics, logs, and traces
- Use Service Level Indicators (SLIs) and Service Level Objectives (SLOs)
- Configure alerting based on user impact rather than technical metrics alone
- Implement log aggregation with proper search and analysis capabilities
Red Flags:
- No correlation between application metrics and business impact
- Alert fatigue due to excessive false positives or low-priority alerts
- No centralized logging making troubleshooting difficult
- Monitoring tools that significantly impact application performance

Suggested

Blue-Green Deployment
Implementation Questions:
- How do you manage two identical production environments for blue-green deployments?
- What load balancer configuration enables instant traffic switching?
- How do you handle database migrations and stateful components?
- What validation and smoke testing occurs before traffic switching?
- How do you implement quick rollback if issues are detected?
- What monitoring detects problems during and after deployments?
Key Considerations:
- Ensure database schemas are backward compatible during deployments
- Implement comprehensive health checks and validation before switching traffic
- Use feature flags to enable gradual rollout of new features
- Monitor key metrics closely during and after traffic switching
Red Flags:
- Database changes that break backward compatibility during deployments
- No automated validation causing deployment of broken code to production
- Insufficient monitoring making it difficult to detect deployment issues
- Resource costs of maintaining duplicate environments without clear benefits
Chaos Engineering
Implementation Questions:
- What chaos engineering tools and frameworks test system resilience?
- How do you design experiments to safely test failure scenarios?
- What failure modes are tested (service failures, network issues, resource exhaustion)?
- How do you measure system behavior and recovery during chaos experiments?
- What safety measures prevent experiments from causing real outages?
- How do you integrate chaos engineering into your development and deployment process?
Key Considerations:
- Start with small, controlled experiments and gradually increase complexity
- Implement proper observability to measure the impact of chaos experiments
- Use hypothesis-driven approaches to validate system resilience assumptions
- Ensure experiments can be stopped immediately if they cause issues
Red Flags:
- Running chaos experiments without proper safety mechanisms or monitoring
- No clear objectives or success criteria for chaos engineering experiments
- Chaos engineering causing more instability than resilience improvement
- Experiments that don't lead to actionable improvements in system design
Container Orchestration
Implementation Questions:
- What container orchestration platform manages your containerized applications?
- How do you implement resource quotas and limits for different workloads?
- What service mesh or ingress controllers handle traffic management?
- How do you implement persistent storage for stateful applications?
- What security policies govern container image scanning and runtime security?
- How do you handle cluster upgrades and maintenance with minimal downtime?
Key Considerations:
- Use namespace separation and network policies for workload isolation
- Implement proper resource management with requests and limits
- Use ConfigMaps and Secrets for externalized configuration
- Implement automated scaling based on resource utilization
Red Flags:
- No resource limits causing resource contention and stability issues
- Poor security practices with privileged containers or weak network policies
- Complex cluster management without proper automation and tooling
- No disaster recovery or backup strategy for cluster state and data

Compliance & Governance

Required

Data Privacy
Implementation Questions:
- What data classification and mapping identify personal and sensitive information?
- How do you implement consent management and user privacy controls?
- What data minimization practices limit collection to necessary information?
- How do you handle data subject requests (access, rectification, deletion)?
- What cross-border data transfer mechanisms comply with regulations?
- How do you conduct privacy impact assessments for new features?
Key Considerations:
- Implement privacy by design principles throughout the development process
- Use data anonymization and pseudonymization techniques where appropriate
- Maintain detailed records of processing activities and data flows
- Implement automated data retention and deletion policies
Red Flags:
- No data inventory or understanding of what personal data is processed
- Collecting more data than necessary for business purposes
- No mechanisms to handle data subject requests in required timeframes
- Cross-border data transfers without appropriate legal basis or safeguards
Audit Logging
Implementation Questions:
- What system activities and events are logged for compliance and security?
- How do you ensure audit log integrity and prevent tampering?
- What retention periods meet regulatory and business requirements?
- How are audit logs protected from unauthorized access and modification?
- What automated analysis detects suspicious patterns or compliance violations?
- How do you handle audit log storage, backup, and archival?
Key Considerations:
- Log all privileged operations and administrative activities
- Use write-once storage or cryptographic checksums for log integrity
- Implement centralized log collection and analysis capabilities
- Include contextual information (user, timestamp, operation, result)
Red Flags:
- Incomplete audit logging missing critical security or compliance events
- Audit logs that can be modified or deleted by unauthorized parties
- No automated analysis or alerting for suspicious audit log patterns
- Insufficient retention periods not meeting regulatory requirements
Access Controls
Implementation Questions:
- What access control models govern user and system permissions (RBAC, ABAC)?
- How do you implement principle of least privilege across all systems?
- What processes manage user provisioning, deprovisioning, and access reviews?
- How are privileged accounts managed and monitored?
- What segregation of duties prevents conflicts of interest?
- How do you handle emergency access and break-glass procedures?
Key Considerations:
- Implement role-based access control with clearly defined responsibilities
- Use automated provisioning and deprovisioning based on HR systems
- Conduct regular access reviews and recertification processes
- Implement just-in-time access for privileged operations
Red Flags:
- Over-privileged accounts with excessive permissions for their role
- No regular access reviews leading to permission creep
- Shared accounts or passwords preventing individual accountability
- No separation of duties for critical business processes
Data Retention
Implementation Questions:
- What data classification determines retention periods for different data types?
- How do you implement automated data lifecycle management?
- What legal hold procedures prevent deletion of litigation-relevant data?
- How do you handle data deletion across distributed systems and backups?
- What validation ensures complete data deletion when required?
- How do you balance retention requirements with storage costs and privacy?
Key Considerations:
- Implement automated data classification and retention policy enforcement
- Use data archival solutions for long-term retention requirements
- Ensure deletion policies cover all data copies including backups
- Document retention decisions and maintain retention schedules
Red Flags:
- No documented data retention policies or inconsistent application
- Retaining data longer than necessary increasing privacy and security risks
- Manual deletion processes prone to errors and incomplete execution
- No mechanism to verify complete data deletion across all systems

Suggested

Compliance Monitoring
Implementation Questions:
- What compliance frameworks and standards are monitored (SOC 2, ISO 27001, PCI DSS, and — for backends serving AI/LLM workloads — the EU AI Act and NIST AI RMF)?
- How do you implement continuous compliance monitoring and assessment?
- What automated tools detect compliance violations and deviations?
- How do you generate compliance reports for auditors and regulators?
- What remediation workflows address identified compliance issues?
- How do you track compliance metrics and improvement over time?
Key Considerations:
- Use compliance as code approaches with automated policy validation
- Implement real-time monitoring with alerting for compliance violations
- Integrate compliance checks into CI/CD pipelines and deployment processes
- Maintain evidence collection and documentation for audit purposes
- For backends that serve AI/LLM workloads, track EU AI Act risk-tiering obligations and NIST AI RMF governance functions alongside SOC 2/ISO 27001/PCI DSS controls — see the enterprise-aiml-checklist for model-level governance
Red Flags:
- Manual compliance checking leading to inconsistent or incomplete coverage
- No real-time visibility into compliance status and violations
- Compliance monitoring that doesn't integrate with operational processes
- Lack of evidence collection making audit preparation difficult
Policy Automation
Implementation Questions:
- What policy engines enforce security and compliance rules automatically?
- How do you implement policy as code with version control and testing?
- What preventive controls block non-compliant actions before they occur?
- How do you handle policy exceptions and temporary overrides?
- What reporting shows policy violations and enforcement effectiveness?
- How do you update and deploy policy changes across all systems?
Key Considerations:
- Use declarative policy languages for consistent rule definition
- Implement policies at multiple enforcement points (network, API, application)
- Test policy changes in non-production environments before deployment
- Provide clear feedback when policies prevent or modify actions
Red Flags:
- Manual policy enforcement prone to human error and inconsistency
- Policies that are overly restrictive and impede business operations
- No testing of policy changes leading to unintended consequences
- Policy enforcement that can be easily bypassed or circumvented
Third-Party Audits
Implementation Questions:
- What frequency and scope of third-party audits meet regulatory requirements?
- How do you prepare for audits with evidence collection and documentation?
- What remediation processes address audit findings and recommendations?
- How do you track and report on audit finding resolution?
- What continuous monitoring reduces surprises during formal audits?
- How do you select qualified auditors with relevant expertise?
Key Considerations:
- Maintain audit readiness with continuous evidence collection
- Use gap assessments to identify and address issues before formal audits
- Implement management systems for tracking audit findings and remediation
- Establish clear timelines and accountability for addressing audit findings
Red Flags:
- No continuous audit preparation leading to scrambled audit responses
- Audit findings that are not addressed in timely manner
- Repeated audit findings indicating systemic process issues
- No independent validation of internal compliance assessments

Documentation

Required

API Documentation
Implementation Questions:
- How is API documentation generated and kept synchronized with code changes?
- What interactive features allow developers to test endpoints directly?
- How do you document authentication, authorization, and error handling?
- What code examples and SDKs support different programming languages?
- How do you handle API documentation versioning and change management?
- What feedback mechanisms help improve documentation quality and completeness?
Key Considerations:
- Use OpenAPI specifications with automated documentation generation
- Provide comprehensive request/response examples and error scenarios
- Implement interactive testing environments and sandbox access
- Include rate limiting, authentication, and troubleshooting guides
Red Flags:
- API documentation that is outdated or inconsistent with actual API behavior
- Missing or incomplete error response documentation
- No interactive testing capabilities or code examples
- Documentation that doesn't include authentication or security requirements
Architecture Docs
Implementation Questions:
- What architectural documentation describes system structure and component relationships?
- How do you document data flows, integration patterns, and external dependencies?
- What diagrams and models communicate architecture to different audiences?
- How do you keep architecture documentation current with system evolution?
- What security and compliance aspects are documented?
- How do you document non-functional requirements and quality attributes?
Key Considerations:
- Use architecture documentation frameworks (C4 model, UML, ArchiMate)
- Document both current state and target architecture with migration plans
- Include disaster recovery, security, and performance considerations
- Maintain documentation in version control with regular reviews
Red Flags:
- Architecture documentation that doesn't reflect actual system implementation
- No documentation of integration patterns or external dependencies
- Missing non-functional requirements and quality attributes
- Architecture documents that are never updated or reviewed
Setup Guide
Implementation Questions:
- What setup documentation covers development environment configuration?
- How do you document deployment procedures for different environments?
- What prerequisite software and configuration requirements are documented?
- How do you provide troubleshooting guides for common setup issues?
- What automation scripts and tools simplify setup and deployment?
- How do you document environment-specific configuration and secrets?
Key Considerations:
- Provide step-by-step instructions with validation checkpoints
- Use automated setup scripts and containerized development environments
- Document both manual and automated deployment procedures
- Include rollback procedures and disaster recovery steps
- Standardize on current LTS runtime versions (Node.js 22 or 24, Python 3.13, Java 21+) across environments to ensure security patches, performance improvements, and long-term support
Red Flags:
- Setup documentation that doesn't work or is missing critical steps
- No automation for complex or error-prone setup procedures
- Missing documentation for different operating systems or environments
- No troubleshooting guidance for common setup or deployment issues
Runbooks
Implementation Questions:
- What operational procedures are documented for common maintenance tasks?
- How do you document incident response and troubleshooting procedures?
- What escalation procedures handle different types of operational issues?
- How do you document system monitoring and alerting responses?
- What backup and recovery procedures are documented and tested?
- How do you maintain runbooks and ensure they remain current?
Key Considerations:
- Create standardized runbook templates for consistency
- Include decision trees and flowcharts for complex scenarios
- Document both manual procedures and automation scripts
- Test runbooks regularly and update based on lessons learned
Red Flags:
- No documented procedures for critical operational tasks
- Runbooks that haven't been tested or validated in real scenarios
- Missing escalation procedures for different severity levels
- Operational documentation that is difficult to find or access during incidents

Suggested

Decision Records
Implementation Questions:
- What format and structure is used for architectural decision records?
- How do you capture the context, options considered, and rationale for decisions?
- What processes ensure ADRs are created for significant architectural choices?
- How are ADRs reviewed, approved, and integrated into the development process?
- What tools and repositories manage ADR storage and discoverability?
- How do you handle ADR updates when decisions change or evolve?
Key Considerations:
- Use lightweight ADR templates that capture essential decision information
- Store ADRs in version control alongside code for traceability
- Include alternatives considered and trade-offs made
- Link ADRs to relevant code, documentation, and project artifacts
Red Flags:
- No documentation of architectural decisions leading to repeated discussions
- ADRs that don't capture sufficient context or rationale for future understanding
- Architectural decisions made without proper evaluation or documentation
- ADRs that are difficult to find or not integrated into development workflows
Change Log
Implementation Questions:
- What changelog format and structure communicates changes effectively?
- How do you categorize changes (features, bug fixes, breaking changes, security)?
- What automation generates changelog entries from commit messages and PRs?
- How do you handle changelog entries for different audiences (users vs. developers)?
- What processes ensure changelog accuracy and completeness?
- How do you communicate significant changes to stakeholders?
Key Considerations:
- Follow semantic versioning and Keep a Changelog conventions
- Use automated tools to generate changelog from structured commit messages
- Highlight breaking changes and migration requirements clearly
- Include links to detailed documentation or issue tracking
Red Flags:
- No changelog or release notes making it difficult to track system evolution
- Changelog entries that don't provide sufficient detail about changes
- Missing information about breaking changes or migration requirements
- Manual changelog maintenance that becomes outdated or inconsistent
Knowledge Base
Implementation Questions:
- What knowledge management platform supports team collaboration and knowledge sharing?
- How do you organize and categorize knowledge for easy discovery?
- What processes ensure knowledge base content remains current and accurate?
- How do you capture and share lessons learned from incidents and projects?
- What search and tagging capabilities help team members find relevant information?
- How do you measure knowledge base usage and effectiveness?
Key Considerations:
- Use collaborative editing tools with version control and change tracking
- Implement content ownership and review processes for quality assurance
- Create templates and standards for different types of knowledge articles
- Integrate knowledge base with development workflows and tools
Red Flags:
- Knowledge scattered across multiple systems without centralized access
- Outdated or inaccurate information that misleads team members
- No ownership or maintenance processes leading to content decay
- Knowledge base that is difficult to search or navigate effectively