ChatGPT prompt for software architecture

Design the architecture for [SYSTEM OR FEATURE]. The users and main jobs are [USERS AND WORKFLOWS]. The current stack and existing constraints are [CURRENT SYSTEM]. Expected scale and reliability needs are [SCALE AND SLOS]. The integrations, data types, and compliance constraints are [INTEGRATIONS AND DATA].

Assume this is a proposal for an engineering review, not an invitation to invent missing requirements. Ask up to 3 clarifying questions only if a required input is missing. Otherwise, state assumptions explicitly and proceed.

Produce a design document with:
1. Problem statement, goals, non-goals, and the critical user flows.
2. A component diagram in Mermaid plus a concise explanation of each service, queue, datastore, cache, and external dependency.
3. Data ownership and lifecycle: source of truth, schema sketch, retention, encryption, access control, and deletion or correction behavior where applicable.
4. API or event contracts with realistic request and response examples, authentication, versioning, idempotency keys, pagination, and error formats.
5. At least two viable architecture options, a decision matrix, and a recommendation tied to constraints rather than fashion.
6. A phased implementation plan including migrations, backward compatibility, observability, rollout, rollback, and test strategy.
7. Small, working code examples in [LANGUAGE OR FRAMEWORK] for the riskiest boundary, with comments only where they clarify a decision.

Address failure modes concretely: duplicate delivery, retries, partial writes, race conditions, timeouts, rate limits, schema changes, poisoned messages, permission failures, and degraded third-party dependencies. Do not claim a component is highly available, secure, or compliant without explaining the mechanism. Before answering, verify that each critical workflow has an owner, persistence path, failure behavior, and observable signal. Also flag decisions that require load tests, threat modeling, or domain-owner confirmation.

Review this proposed architecture for [SYSTEM]: [DESIGN OR DIAGRAM]. Its key requirements are [REQUIREMENTS], and the existing platform constraints are [CONSTRAINTS]. Produce a review memo with blocking risks, important questions, and lower-priority improvements. Trace each critical workflow through data ownership, failure handling, authorization, and observability. Identify hidden coupling, single points of failure, inconsistent consistency models, and migration hazards. For each issue, give a concrete remedy and its trade-off. Do not invent system behavior not present in the materials; mark unknowns. Check that recommendations distinguish must-fix items from preferences.

Design an API contract for [CAPABILITY] used by [CLIENTS]. Existing entities and identifiers are [DOMAIN MODEL], while constraints are [AUTHORIZATION, SCALE, AND COMPATIBILITY]. Return an OpenAPI-style endpoint table, request and response JSON examples, validation rules, error codes, pagination or filtering rules, idempotency behavior, and versioning approach. Explain authorization at the resource level, not just the endpoint level. Include contract-test cases for malformed input, retrying a write, stale data, and forbidden access. Flag domain rules that need product-owner confirmation before implementation.

Plan a safe migration from [CURRENT DESIGN] to [TARGET DESIGN]. The traffic pattern, data size, and uptime requirements are [OPERATING CONDITIONS]. The irreversible risks are [RISKS]. Produce ordered phases for preparation, dual-read or dual-write behavior if needed, backfill, verification, progressive rollout, rollback, and decommissioning. Specify ownership of each data copy, how to detect divergence, and the exact condition for advancing phases. Include example metrics and alerts. Do not assume a big-bang cutover or zero downtime unless the constraints support it. Check that rollback remains possible until the stated commit point.