DEV Community

Manoj Mishra
Manoj Mishra

Posted on

Architecture Traps – When AI Over‑Engineers

#ai #architecture #systemdesign #softwareengineering

Introduction

AI models are trained on a wide range of architectures, from simple monoliths to massive distributed systems. When asked for design advice, they often default to complex, “enterprise‑grade” solutions that may be entirely wrong for your actual scale and team. This post highlights five architectural mistakes AI can lead you into and how to stay grounded.

Mistake 1: Over‑Engineering with AI Suggestions

Description: AI suggests complex distributed solutions when simpler approaches would suffice.

Realistic Scenario: Team needs to store user preferences. AI suggests microservice, event sourcing, and Kafka.

❌ Wrong Prompt:

Design user preferences storage system
Enter fullscreen mode Exit fullscreen mode

⚠️ Why it is wrong: AI may over-engineer without knowing scale (10K users, low write volume).

✅ Better Prompt:

Design user preferences storage for SaaS app with 10K users.

Constraints:

Reads: 10 req/min, Writes: 1 req/min

Simple JSON structure (notification settings, theme)

Existing PostgreSQL database

No budget for additional infrastructure

Need ability to add new preferences without schema changes

Prefer simple solution: JSONB column in users table with partial indexing for queries.
If this needs to scale to 1M users, then consider caching.
Enter fullscreen mode Exit fullscreen mode

💡 What changed: Added scale and constraints to guide toward appropriate simplicity.

Mistake 2: Ignoring Team's Existing Tech Stack

Description: AI recommends new technologies not used by the team, increasing cognitive load and maintenance burden.

Realistic Scenario: Team uses Java Spring. AI suggests Node.js for a new microservice without reason.

❌ Wrong Prompt:

How to implement real-time notifications?
Enter fullscreen mode Exit fullscreen mode

⚠️ Why it is wrong: AI may suggest WebSockets with Node.js/Socket.io instead of leveraging existing tech stack.

✅ Better Prompt:

Implement real-time notifications within existing tech stack.

Current stack:

Backend: Java Spring Boot 3.2

Frontend: React 18

Message broker: RabbitMQ (already used for async tasks)

Deployment: Kubernetes

Prefer solutions using Spring WebSocket (STOMP) over RabbitMQ or Server-Sent Events (SSE) if simpler. Avoid introducing new languages or infrastructure unless absolutely necessary.
Enter fullscreen mode Exit fullscreen mode

💡 What changed: Constrained to existing stack to avoid fragmentation.

Mistake 3: AI Recommends Anti‑Patterns (Distributed Monolith)

Description: AI suggests microservice boundaries that create distributed monoliths with tight coupling.

Realistic Scenario: AI suggests splitting payment service into 10 microservices that all need to call each other synchronously.

❌ Wrong Prompt:

Design microservices for payment system
Enter fullscreen mode Exit fullscreen mode

⚠️ Why it is wrong: AI may create services that are highly coupled, requiring distributed transactions and complex orchestration.

✅ Better Prompt:

Design microservices for payment system following Domain-Driven Design.

Guidelines:

Services should be loosely coupled, communicating asynchronously where possible

Identify bounded contexts: Payment Processing, Fraud Detection, Refunds, Reporting

Prefer eventual consistency over distributed transactions

Each service should own its data (no shared databases)

Avoid synchronous dependencies between services

Start with modular monolith until boundaries are proven

Generate service boundaries with API contracts and data ownership.
Enter fullscreen mode Exit fullscreen mode

💡 What changed: Added principles to prevent distributed monolith anti-pattern.

Mistake 4: No Consideration of Data Consistency

Description: AI proposes solutions without addressing consistency requirements between services.

Realistic Scenario: AI suggests separate services for orders and inventory without discussing eventual consistency implications.

❌ Wrong Prompt:

Split orders and inventory into separate services
Enter fullscreen mode Exit fullscreen mode

⚠️ Why it is wrong: No discussion of how to handle order placement when inventory is temporarily inconsistent.

✅ Better Prompt:

Split orders and inventory into separate services with consistency requirements.

Consistency requirements:

When order placed, inventory must be reserved

Inventory can be eventually consistent (5 sec max)

Order confirmation must show reserved stock

Need to handle inventory service outage during order placement

Options:

Saga pattern with compensating transactions

Outbox pattern with idempotent consumers

Reserve stock synchronously, update asynchronously

Current system: 1000 orders/day, PostgreSQL. Prefer pragmatic approach with transactional outbox.
Enter fullscreen mode Exit fullscreen mode

💡 What changed: Addressed consistency and failure scenarios upfront.

Mistake 5: AI Suggests New Services When Existing Would Suffice

Description: AI recommends building new services instead of extending existing ones, increasing operational complexity.

Realistic Scenario: AI suggests new "audit-log" microservice when existing logging infrastructure could be extended.

❌ Wrong Prompt:

Design audit logging system for compliance
Enter fullscreen mode Exit fullscreen mode

⚠️ Why it is wrong: AI may suggest new service without considering existing ELK stack or database.

✅ Better Prompt:

Design audit logging system leveraging existing infrastructure.

Current infrastructure:

Centralized logging: Elasticsearch (already used)

Message queue: Kafka (already used for events)

Retention: 90 days in Elasticsearch

Requirements:

Compliance: audit trail for sensitive operations

Immutable logs (WORM storage)

Searchable by user, operation, timestamp

10K events/second peak

Prefer: write audit events to Kafka with schema registry, index in Elasticsearch with restricted delete permissions. Avoid creating new service if existing pipeline can be extended.
Enter fullscreen mode Exit fullscreen mode

💡 What changed: Leveraged existing infrastructure to avoid operational overhead.

Summary & Best Practices

  • Start simple and scale only when needed.
  • Stick to your team’s existing tech stack unless there’s a compelling reason to change.
  • Avoid microservices until you have clear bounded contexts and can handle eventual consistency.
  • Explicitly address data consistency and failure scenarios.
  • Reuse existing infrastructure instead of creating new services.

Good architecture is about balance. Use AI to explore options, but always weigh them against your real constraints.

Top comments (1)

Collapse
 
acytryn profile image
Andre Cytryn •

the constraint-first prompting approach here is the key insight. i've seen teams spend weeks debating kafka vs rabbitmq for a 100 req/day workflow because the AI defaulted to enterprise patterns. explicitly adding 'no new infrastructure' and your current stack cuts through 90% of that noise.

the modular monolith advice for the payment example is particularly good. starting with clear bounded contexts as packages in a single codebase lets you prove the seams before paying the distributed systems tax. you know the boundaries are right when splitting actually becomes easy.