AI and System Design

Why Start with System Design?

The most expensive mistakes in software don't happen in functions — they happen in architecture. Choosing the wrong database, the wrong component structure, or the wrong API pattern creates problems that compound over months, eventually requiring painful rewrites.

AI makes it easier to draft architecture options and lists of trade-offs. This does not replace the experience or system knowledge needed to evaluate them, and a quick conversation is not an architecture validation.

AI as Architect

The first and most powerful use of AI in system design is asking it to propose a complete architecture for your project. Give it your requirements and let it design the system before you write any code.

Design a system architecture for a family schedule planner.



Requirements:

- React frontend (TypeScript)

- Node.js / Express backend

- MySQL database

- REST API

- Should support multiple family members

- Needs to scale to ~1000 concurrent users eventually



Show:

1. High-level system diagram (frontend → API → database)

2. React component hierarchy

3. API endpoint structure

4. Database tables and relationships

5. Where state lives (client vs. server)



Don't write implementation code — just the blueprint.

This prompt can produce a draft architectural overview: a map of the system's layers, connections, and data flow. Treat it as a proposal to evaluate against real requirements, constraints, and failure modes.

Visualizing Architecture

AI-generated architecture descriptions become much easier to evaluate when visualized. Here's the kind of layered view you should ask for — and what a typical three-tier architecture looks like:

You can ask AI to generate diagrams in various formats — ASCII art (works in any text context), Mermaid syntax (renders as actual diagrams in many tools), or structured lists. The format matters less than having a visual map to reason about.

Compare Alternatives

Do not accept the first architecture uncritically. Comparing alternatives can expose trade-offs and hidden assumptions, but the comparison is only as reliable as the context and evidence supplied.

Give me three different architecture approaches for this project.



For each approach:

- Describe the architecture

- List pros and cons

- Identify the main risk

- Rate complexity (simple / moderate / complex)

- Say when you'd choose this approach



Then recommend which one I should use for an MVP,

and which one I should migrate to later if the

project grows.

This prompt forces AI to think comparatively — not just generate one plausible answer, but evaluate trade-offs across multiple options. The "recommend for MVP vs. later" question is especially valuable because it separates what you need now from what you might need eventually, preventing over-engineering.

Monolith vs. Microservices

A recurring architectural decision is choosing between a monolith and separately deployed services. AI can help structure the comparison if you provide workload, ownership, deployment, and reliability constraints.

For this project, should I use a monolith or microservices?



Context:

- Solo developer (for now)

- Expected users: ~500 initially

- Team might grow to 2-3 developers in 6 months

- Budget: low (personal project)



Be honest about the trade-offs.

When is microservices overkill for a project like this?

For many solo or small-team projects, especially at the MVP stage, a well-structured monolith is a reasonable default. Extracting services later is possible but can be costly, so base that decision on measured scaling, deployment, ownership, and reliability needs rather than a predicted threshold.

Database Design

AI can draft a database schema from entities and relationships. Treat normalization, indexes, constraints, migrations, authorization boundaries, and deletion behavior as review items rather than assumed properties of the draft.

Design a MySQL database schema for this family planner.



Entities:

- Family (name, created date)

- FamilyMember (name, color, avatar, belongs to family)

- Activity (name, day, start time, end time, belongs to member)



Requirements:

- Proper foreign keys and relationships

- Indexed for common queries (activities by day, by member)

- Soft delete support (deleted_at)

- Created/updated timestamps on all tables



Show CREATE TABLE statements with comments explaining

design decisions.

AI may produce a useful SQL draft with constraints, indexes, and timestamp patterns. Validate syntax against the selected database version, test migrations and rollback, inspect query plans using realistic data, and review authorization and tenancy boundaries before treating it as production-ready.

API Design

A well-designed API is the contract between your frontend and backend. AI can generate consistent, RESTful endpoints that follow naming conventions and cover all CRUD operations.

Design REST API endpoints for this family planner.



Requirements:

- Follow REST conventions

- Consistent naming

- Proper HTTP methods

- Include authentication endpoints

- Pagination for list endpoints

- Error response format



Show each endpoint with: method, path, request body,

and response format.

A typical result might include:

Scalability and Security Review

Two dimensions that beginners consistently neglect — and that AI can surface proactively — are scalability bottlenecks and security vulnerabilities.

Analyze this architecture for scalability bottlenecks.



What will break first as users grow from 100 → 1,000 → 10,000?

What's the cheapest fix at each stage?

Review this system design for security vulnerabilities.



Consider:

- Authentication / authorization gaps

- Data exposure risks

- Input validation

- SQL injection vectors

- CORS configuration

- API rate limiting

Early review can reduce rework, especially for trust boundaries, authorization, data ownership, and failure handling. The cost of a change depends on how widely the decision has propagated and how reversible it is.

The Architecture Review Loop

System design with AI follows a specific iteration pattern that's different from the code-level iteration in earlier chapters. Here, you're iterating on decisions, not on implementation.

Most projects need two or three passes through this loop. The first pass creates the skeleton, the second pass identifies and fixes weaknesses, and the third pass simplifies anything that was over-designed. Only then do you start coding.

Common Mistakes

Related Guides