Design Interview

Goal: Identify all systems involved and their connection details.

Questions:

• Where does data come from (source systems)?
• Where does data go (destination systems)?
• What protocols or APIs are used?
• Are there intermediary systems (enrichment, validation)?

Example Exchange:

AI: Where do orders come from?

You: The e-commerce website posts orders to an HTTP endpoint 
     we need to expose.

AI: What is the destination for validated orders?

You: They go to a Kafka topic called "warehouse.orders" 
     that our WMS consumes.

AI: Do you need to connect to any other systems for 
     enrichment or validation?

You: Yes, we need to look up customer credit status in 
     a PostgreSQL database before sending to the warehouse.

Illustrative component selection: After the adaptive discovery interview is complete, the AI searches the catalog and reads the component documentation before assembling the design. For the requirements above, that selection could produce:

AI: (catalog search + component docs) ✓ platform-http for the selected runtime
AI: (catalog search + component docs) ✓ kafka
AI: (catalog search + component docs) ✓ sql

If discovery identifies a requirement for “SuperQueue” and no matching component is found during component selection, the AI asks for clarification before assembling the design:

AI: I couldn't find a component for "SuperQueue" in the 
    Camel catalog. Could you clarify which messaging system? 
    (ActiveMQ, RabbitMQ, Kafka, AWS SQS, etc.)

This is Iron Law #1 in action: no component name enters the design without MCP verification.

Goal: Understand input/output formats and transformation requirements.

Questions:

• What format does input data arrive in? (JSON, XML, CSV, etc.)
• What format should output data be in?
• Are transformations needed between input and output?
• Are there schemas or data contracts?
• Field-level mapping detail — conditional follow-up, asked only when field mapping is needed between XML and JSON formats

Example Exchange:

AI: What format do orders arrive in from the website?

You: JSON with fields like orderId, customerId, items array, 
     and totalAmount.

AI: What format does the Kafka message need to be?

You: Also JSON, but we need to add customer credit status 
     and warehouse location code.

AI: This sounds like a field-level transformation. Would you 
     like to use DataMapper for reliable mapping, or simple 
     JSON manipulation?

You: Let's use DataMapper since this needs to be very reliable.

DataMapper Decision: If transformations are complex, the AI offers DataMapper. It uses inline Groovy when both schemas are absent or the mapping has fewer than 20 leaf fields; it uses XSLT only when the mapping has at least 20 leaf fields and at least one schema. For simple transformations, the AI suggests JSON processors or bean methods.

Goal: Identify business logic, validation rules, and processing steps.

Questions:

• What validations are required?
• What business rules must be enforced?
• Are there calculations or enrichments?
• Any conditional routing (if-then-else)? — the multi-path routing follow-up is asked only when you name several destinations

Example Exchange:

AI: What validations are needed for incoming orders?

You: The orderId must be unique, totalAmount must be greater 
     than zero, and customerId must exist in our database.

AI: What should happen if validation fails?

You: Invalid orders go to a separate Kafka topic "orders.invalid" 
     for manual review, with the validation error message included.

AI: You mentioned adding credit status. What's the business rule?

You: If creditStatus is "BLOCKED", don't send to warehouse. 
     Route to "orders.pending" topic instead.

Conditional Routing: The AI identifies choice/when patterns and includes them in the design.

Goal: Define how failures are handled across different failure modes.

Questions:

• What should happen if source system is unavailable?
• What about destination system failures?
• Should there be retries? How many?
• Dead letter queues or error topics?
• Alerting or notifications on errors?

Example Exchange:

AI: What should happen if the database lookup for customer 
    credit status fails?

You: Retry up to 3 times with exponential backoff. If all 
     retries fail, send to "orders.error" topic.

AI: What about Kafka publish failures?

You: Kafka should be highly available, but if publish fails, 
     log the error and retry indefinitely until it succeeds.

AI: Should anyone be notified of errors?

You: Yes, send an email to ops@company.com if we get more 
     than 10 database failures in 5 minutes.

Error Classification: The AI categorizes errors:

• Transient errors → retry
• Validation errors → route to dead letter / invalid topic
• System errors → alert

Goal: Capture non-functional requirements and monitoring needs.

Questions:

• What is the expected throughput?
• What are latency requirements?
• How should metrics be exposed?
• What logging is needed?
• Any tracing requirements?

Example Exchange:

AI: What is the expected order volume?

You: Peak hours see about 500 orders per minute. Off-peak 
     is around 50 per minute.

AI: What latency is acceptable?

You: Each order should be processed end-to-end in under 
     2 seconds.

AI: What metrics do you need to track?

You: Total orders received, validation pass rate, database 
     lookup time, Kafka publish time, and error count by type.

Constitution Rule 5: Every route requires a routeId and description. Metrics, logging, tracing, and correlation are added when the project’s monitoring requirements call for them.

Goal: Record reasonable adjacent capabilities that this iteration deliberately excludes, together with the reason for each boundary.

Questions:

• What related capabilities should this iteration not implement?
• Why is each capability out of scope?

Example Exchange:

AI: Which adjacent capabilities are deliberately out of scope
    for this iteration, and why?

You: Do not add an order-status API; that is a separate
     consumer-facing capability with its own security design.
     Historical replay remains with the existing Kafka platform,
     and operations will use the existing monitoring dashboard.

Why this matters: Explicit boundaries keep planning and implementation focused while preserving the rationale for future design changes.

The systems, technologies, protocols, and source/target roles involved in the integration.

One complete design per named flow, including its target module, purpose, MCP-verified source and sink, transformations, error handling, configuration properties, and decision rationale.

• order-reception — HTTP source, validation and enrichment steps, Kafka sink
• Source/sink options — exact catalog-backed endpoint options
• Error handling — retry/DLQ/log/stop strategy and applicable resilience patterns
• DataMapper — field mappings and approach when transformation requires it

Each component and EIP records why it was selected and which constraints influenced the choice.

Project-wide performance, security, monitoring, and constraint decisions. When no special requirement applies, the spec records the corresponding standard behavior instead of inventing one.

• Performance: throughput, latency, and deployment targets when supplied
• Security: authentication, sensitive data, and compliance requirements when supplied
• Monitoring: metrics, logging, and tracing requirements when supplied
• Constraints: technology, team, timeline, and other project requirements

An explicit checklist showing how every flow is designed to meet all eight Constitution rules, including catalog verification and the Forage infrastructure ladder.

• Route Structure and Single Responsibility
• Separation of Concerns and Naming Conventions
• Observability and External Configuration
• Component Catalog Verification and Infrastructure via Forage

Greenfield: /camel-brainstorm extracts all available evidence first, then asks only the project, per-flow, or conditional cross-cutting questions still needed. Complete supplied requirements can go directly to runtime/version selection, MCP catalog verification, and design assembly without clarification.

Migration: /camel-migrate parses existing artifacts (Mule XML, Camel 2.x XML, etc.) and generates the Design Specification by analyzing existing flows. It skips the generic Socratic interview, but confirms unknown or inferred fields before presenting the complete design for approval.

The interview is defined in the brainstorm skill. You can customize project-specific prompts while retaining the adaptive evidence-first rules.

Example: Add a project-specific compliance follow-up when regulated data is present:

### Regulated Data Follow-Up (conditional)
If supplied material identifies regulated data, ask for the applicable retention
and audit requirements unless those decisions are already documented.

Record the result under Section 4, Cross-Cutting Concerns; do not add a new fixed interview round or change the greenfield spec schema.

Asynchronous fire-and-forget — accept immediately, process in background.

AI: Should the HTTP endpoint wait for Kafka confirmation?

You: Return immediately with HTTP 202 Accepted

AI: Should we use an intermediary queue for reliability?

You: Yes, use SEDA for async processing

Design Output: Two flows: REST → SEDA (return 202), then SEDA → Kafka.

Complex multi-system — parallel writes with distributed transaction handling.

AI: Where does data go?
You: Three places: inventory DB, CRM, and shipping email

AI: Sequence or parallel?
You: Parallel, but rollback all if any fails

AI: This requires Saga pattern. Should we use it?
You: Yes, with compensating transactions

Design Output: Multi-flow with Saga coordination.