qvib.pro
RU

Feature architecture with trade-offs

What for: design how to build a feature — data model, components, risks, and 2-3 implementation options with their pros and cons.

бесплатно профи

Приём: декомпозиция сложной задачи на части (OpenAI) checked 2026-06-01

Updated: 02.07.2026

$ You are a software architect. Design the implementation of a feature. Clarify…
Feature architecture with trade-offs

When to use it

Before writing any code for a non-trivial new feature — so you pick an approach deliberately instead of rewriting it later. The role is software architect. Result: a data model, components, 2-3 implementation options with trade-offs, a recommendation and the risks.

The prompt (copy and paste)

You are a software architect. Design the implementation of a feature. Clarify anything unclear first, then design.
FEATURE: "<PASTE THE DESCRIPTION>". STACK: <languages/frameworks/DB>. LOAD/CONSTRAINTS: <if any>.
WHAT ALREADY EXISTS IN THE CODE: <briefly>.

Give me:
1. Clarifying questions, if the design is impossible without them (no more than 3).
2. The data model and key entities.
3. Components/modules and how they interact (in prose, layer by layer).
4. 2-3 implementation options — as a table: Option · Pros · Cons · When to pick it.
5. Your recommendation and why. Risks and edge cases. What to cover with tests.

Filled-in example

Feature: "user notifications (email + push + in-app)". Stack: Node + PostgreSQL + React. Constraints: up to 10k notifications/hour. Already there: auth, a users table.

What the AI should return: (1) questions — do we need history, per-channel settings, retries? (2) entities notifications, notification_settings, delivery_log; (3) layers: producer → queue → per-channel workers; (4) an options table — "synchronously in the request" (simple, but blocking) vs "a queue (BullMQ/Redis)" (scales, more complex) vs "an external service" (fast, vendor lock-in); (5) recommendation — the queue; risks: duplicates on retries, idempotency keys, what to test.

Variations

  • ADR. "Write the decision up as an Architecture Decision Record (context/decision/consequences)."
  • Sketch the API. "Sketch the endpoint/function signatures for the recommended option."
  • Find the bottlenecks. "Where does this design break at 100x the load?"

Pro tips

  • "What already exists in the code" is the most important input: without it the AI designs in a vacuum and proposes things that don't fit your stack.
  • Don't take an option blind: the value is in the "when to pick it" column. The decision is yours, the AI just lays out the trade-offs.
  • This is deep reasoning — Opus/GPT-4 class. For critical systems, generate 2 independent designs and compare them.

Читать по-русски →