"I need a simple todo app." Three hours later, the AI had designed a distributed system with microservices, event sourcing, CQRS, a service mesh, and Kubernetes orchestration. For a todo app. That would have maybe 100 users.
Welcome to AI Architecture Astronauts - where every problem needs the entire AWS service catalog to solve.
The Simple Request
// My request to the AI
const requirements = {
app: "Todo list",
features: [
"Add todos",
"Mark as complete",
"Delete todos"
],
users: "Maybe 100, mostly me",
budget: "$10/month max"
};
Here's what the AI proposed for my todo app:
// AI's proposed architecture (I wish I was joking)
const todoArchitecture = {
frontend: {
framework: "Micro-frontend with Module Federation",
services: [
"todo-list-ui",
"todo-input-ui",
"todo-filter-ui",
"shared-components-library"
]
},
backend: {
pattern: "Event-driven microservices",
services: [
"todo-command-service",
"todo-query-service",
"user-service",
"notification-service",
"audit-service",
"analytics-service"
],
infrastructure: [
"API Gateway",
"Service Mesh (Istio)",
"Message Queue (Kafka)",
"Event Store",
"Read Database (PostgreSQL)",
"Write Database (MongoDB)",
"Cache Layer (Redis)",
"Search Engine (Elasticsearch)"
]
},
deployment: {
platform: "Kubernetes",
monitoring: ["Prometheus", "Grafana", "Jaeger"],
ci_cd: "GitOps with ArgoCD"
}
};
For. A. Todo. App.
// What I actually built
const todos = [];
app.post('/todos', (req, res) => {
todos.push({ id: Date.now(), ...req.body });
res.json({ success: true });
});
app.get('/todos', (req, res) => res.json(todos));
// Done. Ship it.
Request: "Add a contact form to the website"
AI's solution:
- Separate microservice for form handling
- Message queue for async processing
- ML service for spam detection
- Blockchain for submission proof
- GraphQL API with subscriptions
- Real-time analytics dashboard
What we built: An HTML form that sends an email.
// AI's design for storing user profiles
interface UserAggregate {
applyEvent(event: DomainEvent): void;
getUncommittedEvents(): DomainEvent[];
markEventsAsCommitted(): void;
}
class UserCreatedEvent implements DomainEvent {
constructor(
public readonly userId: UUID,
public readonly email: Email,
public readonly timestamp: DateTime
) {}
}
class UserProjection {
@EventHandler(UserCreatedEvent)
onUserCreated(event: UserCreatedEvent): void {
// Update read model
}
}
// ... 47 more files
The actual requirement: Store username and email.
- Training on "Best Practices" Articles - Every Medium post about architecture
- No Sense of Scale - Can't differentiate between Google and a blog
- Pattern Matching Gone Wild - Saw microservices? Must use microservices!
- Resume-Driven Development - Learned from developers padding their skills
// AI applying every pattern it knows
class TodoItemFactoryBuilderProvider {
private strategyFactory: StrategyFactory;
private observerManager: ObserverManager;
private chainOfResponsibility: HandlerChain;
constructor(
private readonly decoratorFactory: DecoratorFactory,
private readonly visitorAcceptor: VisitorAcceptor,
private readonly mementoCaretaker: MementoCaretaker
) {
this.initializeFacade();
this.setupBridge();
this.configureAdapter();
}
// Just to create a todo item...
}
Things AI adds "for future scalability":
- Multi-region database replication (for 10 users)
- Caching layer (for data that never changes)
- API versioning (v1 is still the only version)
- Feature flags system (two features total)
- A/B testing framework (one user - me)
// AI's "simple" configuration file
const config = {
kubernetes: {
deployments: 14,
services: 14,
configMaps: 23,
secrets: 18,
ingresses: 4,
persistentVolumes: 7
},
terraform: {
modules: 12,
resources: 186,
providers: 9
},
dockerImages: 14,
npmPackages: 347,
totalFiles: 1847,
linesOfYaml: 4672,
actualBusinessLogic: 134 // < 3% of codebase
};
// How to constrain AI architecture astronauts
const ARCHITECTURE_CONSTRAINTS = {
rules: [
"Must run on a $5/month VPS",
"Must deploy in under 5 minutes",
"Junior dev must understand it in 15 minutes",
"No more than 3 moving parts",
"No technology unless it solves a current problem"
],
banned_unless_justified: [
"Microservices",
"Event sourcing",
"CQRS",
"Kubernetes",
"Service mesh",
"Multiple databases",
"Message queues"
],
questions_to_ask: [
"What problem does this solve?",
"What's the simpler alternative?",
"Will we need this in 6 months?",
"Can we add it later if needed?"
]
};
// Give AI a complexity budget
"You have 10 complexity points to spend:
- Database: 3 points
- API: 2 points
- Frontend framework: 3 points
- Auth system: 2 points
- Additional services: 5 points each
Stay under budget."
// The complexity rubric that actually works
class ComplexityCalculator {
calculate(architecture) {
let score = 0;
// Each technology has a cost
const costs = {
'basic_web_framework': 1,
'database': 2,
'cache': 2,
'queue': 3,
'microservice': 5,
'kubernetes': 10,
'service_mesh': 15,
'event_sourcing': 20
};
// Calculate total
for (const [tech, cost] of Object.entries(costs)) {
if (architecture.includes(tech)) {
score += cost;
}
}
// Penalties
if (architecture.services > architecture.developers * 2) {
score += 10; // More services than developers can handle
}
if (architecture.databases > 1) {
score += 5 * (architecture.databases - 1); // Multiple DB complexity
}
return score;
}
recommend(score) {
if (score < 10) return "Appropriately simple ✓";
if (score < 20) return "Getting complex, justify each addition";
if (score < 30) return "Too complex, remove unnecessary parts";
return "Architecture astronaut alert! Start over.";
}
}
// Real examples of AI overengineering
const horrorStories = [
{
request: "User login form",
ai_solution: "OAuth2 + SAML + biometric auth + blockchain identity",
actual_need: "Username/password with remember me"
},
{
request: "Store product images",
ai_solution: "CDN + image processing pipeline + AI optimization + multiple formats",
actual_need: "Upload to S3 bucket"
},
{
request: "Send welcome email",
ai_solution: "Email service + queue + retry logic + analytics + A/B testing",
actual_need: "SMTP call when user signs up"
},
{
request: "Basic search",
ai_solution: "Elasticsearch cluster + ML ranking + personalization",
actual_need: "SQL LIKE query"
}
];
// Start simple
v1: Single file, single table
v2: Add authentication
v3: Add API
v4: Add caching (if needed)
v5: Consider splitting services (probably not needed)
// Not the AI approach:
v1: 47 microservices and a service mesh
- More configuration than code
- Need a diagram to explain the diagram
- Using Kubernetes for a static site
- "Eventual consistency" for a todo list
- More services than users
- Abstract factory factories
If you can't explain the architecture in 10 minutes to a junior developer, it's too complex. My todo app architecture explanation:
" "Express server, SQLite database, todos table. POST to add, GET to list, DELETE to remove. The end.""
Time: 12 seconds.
Six months later:
- Todo app still running on a single file
- Zero maintenance required
- 100% uptime (it's so simple it can't break)
- Total AWS bill: $0
- Kubernetes clusters needed: 0
The Architecture Pattern Decoder
When AI suggests architecture, here's what it really means:
ai_says: "We need microservices for scalability"
reality: "I learned this from a Netflix blog post"
ai_says: "Event sourcing provides audit trail"
reality: "I don't understand your actual audit requirements"
ai_says: "CQRS will improve performance"
reality: "I'm applying patterns without measuring"
ai_says: "Service mesh for observability"
reality: "I don't know what you actually need to observe"
ai_says: "Kubernetes for container orchestration"
reality: "I assume every app needs Google-scale infrastructure"
How to Ground Your AI Architect
1. Force Concrete Scenarios
// Instead of: "Design a scalable architecture"
// Ask: "Design for these specific scenarios"
const concreteScenarios = {
current: {
users: 100,
requests_per_day: 1000,
data_size: "10MB",
budget: "$50/month",
team_size: 2
},
sixMonths: {
users: 500,
requests_per_day: 5000,
data_size: "100MB",
budget: "$200/month",
team_size: 3
},
constraints: [
"Must deploy in 30 minutes",
"Single developer can maintain",
"Works on a 2GB RAM server",
"Can rollback in 5 minutes"
]
};
2. The Architecture Minimizer Prompt
You are an architecture minimizer. Your goal is to solve problems with the least possible complexity.
Rules:
1. Start with a single file if possible
2. Add components only when current solution fails
3. Prefer boring technology
4. Optimize for deletion, not addition
5. If it worked in 2010, it probably still works
For each component suggested, you must:
- Prove the simpler alternative fails
- Show concrete metrics requiring it
- Estimate maintenance hours/month
- Define removal criteria
3. The Real Cost Calculator
// AI never considers these costs
const realArchitectureCosts = {
kubernetes: {
setup_hours: 40,
monthly_maintenance: 20,
required_expertise: "High",
debugging_complexity: "Very High",
minimum_viable_nodes: 3,
monthly_cost: "$300+"
},
simple_vps: {
setup_hours: 2,
monthly_maintenance: 1,
required_expertise: "Low",
debugging_complexity: "Low",
minimum_viable_nodes: 1,
monthly_cost: "$5-20"
},
// For a 100-user app, which makes sense?
};
Success Stories: Simple Architectures That Scale
Case 1: The Monolith That Could
- Stack: Rails + PostgreSQL
- Users: 0 → 100K
- Time to add features: Hours, not weeks
- Ops burden: 2 hours/week
- Architecture discussions: 0
Case 2: The Boring Stack
- Stack: Express + SQLite → PostgreSQL (at 10K users)
- Services: 1
- Deployment: Git push
- Monitoring: Basic health check
- Revenue: $2M/year
Case 3: The Anti-Pattern That Works
- Stack: PHP + MySQL (yes, really)
- Framework: None (custom)
- Scaling solution: Bigger server
- Cost: $100/month
- Uptime: 99.9%
The Architecture Decision Framework
class ArchitectureDecision {
shouldUseComplexArchitecture(project) {
// Most projects fail this test
const requirements = {
hasMillionsOfUsers: project.users > 1000000,
needsGlobalDistribution: project.regions > 3,
hasStrictCompliance: project.regulated === true,
multipleTeams: project.teams > 5,
complexDomain: project.domainComplexity > 8
};
const complexityScore = Object.values(requirements)
.filter(Boolean).length;
if (complexityScore < 3) {
return {
decision: "USE_SIMPLE_ARCHITECTURE",
recommendation: "Monolith with good modularity",
reasoning: "Complexity not justified by requirements"
};
}
return {
decision: "CONSIDER_COMPLEX_ARCHITECTURE",
recommendation: "Start simple, evolve as needed",
reasoning: "Some complexity may be warranted"
};
}
}
The Bottom Line
Next time AI proposes a 47-service architecture for your blog, remember:
- Stack Overflow runs on a monolith
- Wikipedia runs on PHP
- Craigslist uses Perl
- These handle more traffic than your app ever will
Start simple. Stay simple as long as possible. Add complexity only when you have the specific problem it solves, not the problem you might have someday.
Your future self (maintaining this at 3 AM) will thank you.
References and Further Reading
- "Choose Boring Technology" - Dan McKinley
- "The Majestic Monolith" - DHH
- "You Aren't Gonna Need It" - Martin Fowler
- "The Cost of Complexity" - Simple Made Easy
Remember: The best architecture is the one you don't have to explain.