AI Prompts for Architecture

Design a system architecture for: [system description].
Scale: [users/requests per day]. SLA: [uptime + latency]. Budget tier: [startup/mid/enterprise].
Deliver: component overview (what each service does), data flow description, database selection + schema sketch, API design (main endpoints), auth approach, how to handle peak load, failure modes + mitigations, and a V1 vs future scope split.

Help me decide whether to build [system] as a monolith or microservices.
Team size: [size]. Expected scale: [scale]. Complexity: [description]. Timeline: [timeline].
Walk through the tradeoffs for this specific context — not a general comparison. Give a clear recommendation with the top 3 reasons. Include a "when to revisit this decision" trigger.

Help me choose the right database for this use case:
Data type: [structured/unstructured/time-series/graph/etc.]. Read/write ratio: [ratio]. Query patterns: [describe]. Scale: [rows + requests/sec]. Consistency requirements: [strong/eventual].
Compare 3 database options with tradeoffs. Recommend one with justification. Include schema design sketch for the recommended option.

Design the API architecture for [product/feature].
Consumers: [web app/mobile/third-party]. Auth: [user types + permissions]. Scale: [requests/day].
Define: API style (REST/GraphQL/gRPC — with justification), versioning strategy, endpoint structure (resources + actions), pagination approach, rate limiting design, error response format, and webhook design (if needed). Include an OpenAPI summary.

Design a caching strategy for [system/feature].
What to cache: [data type + size]. Read frequency: [requests/sec]. Freshness requirement: [max acceptable staleness]. Cache backend: [Redis/Memcached/CDN/in-memory].
Define: cache key schema, TTL policy, invalidation triggers, cache warming strategy, cache stampede prevention, and what NOT to cache. Include code pattern for the cache-aside pattern.

Design an event-driven architecture for [use case].
Current: [synchronous/monolithic approach]. Problem: [what synchronous coupling is causing].
Define: events to produce (name, schema, producer), events to consume (name, consumer, action), message broker choice + justification, event ordering requirements, exactly-once vs at-least-once delivery, dead letter queue design, and how to handle schema evolution over time.

Design the authentication and authorization architecture for [product].
User types: [roles]. Platforms: [web/mobile/API]. Requirements: [SSO/MFA/social login/etc.].
Design: auth flow (login → token → refresh → logout), token storage strategy (per platform), session management, permission model (RBAC/ABAC), API key management for machine-to-machine, and security hardening checklist.

Create a migration plan from a monolithic [language/framework] app to microservices.
Monolith size: [LOC / number of modules]. Team size: [size]. Timeline: [acceptable timeline].
Phase 1: Identify seams (what to extract first). Phase 2: Strangler fig pattern (running both in parallel). Phase 3: Data separation. Phase 4: Full cut-over.
Include: risk per phase, how to keep the system running during migration, and rollback triggers.

Design the cloud infrastructure architecture for [product] on [AWS/GCP/Azure].
Scale: [users + traffic]. Budget: [$/month]. Compliance: [GDPR/HIPAA/SOC2/none].
Define: compute (containers/serverless/VMs), networking (VPC, load balancer, CDN), storage, database tier, CI/CD pipeline, monitoring + alerting stack, secret management, backup strategy, and estimated monthly cost breakdown.

Design a data pipeline for [use case: analytics/ML/reporting/ETL].
Data sources: [sources]. Data volume: [GB/day]. Latency requirement: [real-time/near-real-time/batch]. Destination: [data warehouse/lake/database].
Define: ingestion layer, transformation logic, storage format, orchestration tool, data quality checks, lineage tracking, and failure handling. Recommend a stack for this scale and budget.

Design a multi-tenant architecture for a SaaS product: [product description].
Tenancy model: [shared DB / schema per tenant / DB per tenant] — recommend if not decided.
Cover: data isolation strategy, tenant identification (URL/header/JWT claim), resource limits per tenant, tenant onboarding/offboarding flow, cross-tenant data leakage prevention, and how the architecture handles a tenant 10× larger than average.

Design an observability architecture (logging, metrics, tracing) for [system].
Stack: [language + infrastructure]. Team: [size]. Current problem: [blind spots + MTTR issue].
Define: what to log (structured log schema), what to metric (key service indicators), how to trace requests across services, alerting thresholds and on-call runbooks, dashboard design (what to show on the main screen), and the tech stack recommendation (open-source vs managed).

Design a feature flag system for [product].
Use cases: [gradual rollouts/A/B testing/kill switches/beta users]. Team size: [size]. Stack: [stack].
Define: flag types and data model, evaluation logic (where flags are resolved — client/server/edge), targeting rules (user segment, %, allow/block lists), flag lifecycle (creation → rollout → cleanup), SDK interface design, and how to prevent flag debt from accumulating.

Review the security architecture of this system:
Description: [system description]. Data sensitivity: [PII/PHI/financial/public]. Attack surface: [public API/internal/both].
Assess: authentication and session security, authorisation model, data encryption (in transit + at rest), input validation approach, dependency vulnerability exposure, secrets management, audit logging, and incident response readiness. Produce a risk-ranked finding list with remediation priority.

Review this system design for scalability bottlenecks at [10×] current load:
Current architecture: [describe]. Current load: [requests/sec + data volume]. Target: [10× load].
Identify: single points of failure, stateful components that block horizontal scaling, database query bottlenecks, synchronous choke points, and missing caches. For each: current behaviour at scale → recommended change → estimated effort.

Help me choose the tech stack for [project type].
Team experience: [languages/frameworks the team knows]. Scale requirement: [users/data]. Timeline: [mvp in X months]. Budget for infrastructure: [$/month].
Evaluate options across: frontend, backend, database, auth, hosting, and CI/CD. Score each dimension on: team fit, ecosystem maturity, cost, scalability, and hiring pool. Give a final recommended stack with justification.

Design a disaster recovery plan for [system].
RTO (max downtime): [hours]. RPO (max data loss): [hours/minutes]. Infrastructure: [cloud + region].
Define: backup strategy (frequency, retention, testing), failover architecture (active-passive vs active-active), data replication approach, recovery runbook (step-by-step), DR test schedule, and estimated cost. Include a table of failure scenarios with recovery procedure for each.

Design a service mesh implementation for [microservices system].
Current pain: [service discovery/mTLS/observability/traffic management]. Tech: [Kubernetes/Docker/VMs].
Compare: Istio vs Linkerd vs Consul for this use case. Recommend one with justification. Define: sidecar proxy pattern, mTLS configuration, traffic policies (canary/circuit breaker/retry), observability integration, and a phased adoption plan starting with the highest-value service.

Design a serverless architecture for [use case].
Cloud provider: [AWS Lambda/GCP Cloud Functions/Azure Functions]. Expected invocations: [per day]. Duration per invocation: [ms].
Design: function boundaries (what each function does), trigger types (HTTP/event/schedule), cold start mitigation strategy, state management (where state lives), error handling and retry logic, local development setup, and cost estimate vs equivalent EC2/container approach.

Design the code organisation and module structure for a [language/framework] project of [size: small/medium/large].
Project type: [API/web app/CLI/library]. Team size: [size].
Define: folder structure with rationale for each directory, module boundary rules (what belongs where), dependency direction rules, shared code conventions, test file co-location strategy, and how the structure scales as the project grows from 10K to 100K LOC.