Project Interview Bible β‘ Recently updatedUpdated on Jun 30, 2026 β this content may still be evolving.
Explaining Your Project Architecture
How to describe, draw, and defend your systemβs structure in interviews.
What Interviewers Want
- A clear mental model of how pieces connect
- Justification for technology choices
- Awareness of what would break at scale
- Honesty about shortcuts you took (and why)
The Standard Student Architecture
Most student fullstack projects follow this pattern:
βββββββββββββββββββββββββββββββββββββββββββββββββββ
β CLIENT β
β React / Next.js (browser) β
β - UI components, routing, state management β
ββββββββββββββββββββββββ¬βββββββββββββββββββββββββββ
β HTTPS (REST API / WebSocket)
ββββββββββββββββββββββββΌβββββββββββββββββββββββββββ
β SERVER β
β Node.js + Express β
β - Routes, middleware, business logic β
β - Auth middleware, validation β
ββββββββββββ¬ββββββββββββββββββββββββ¬βββββββββββββββ
β β
ββββββββββββΌβββββββββββ ββββββββββΌβββββββββββββ
β DATABASE β β EXTERNAL SERVICES β
β PostgreSQL/MongoDB β β - Cloudinary (images) β
β - Users, data β β - SendGrid (email) β
β - Migrations β β - Stripe (payments) β
βββββββββββββββββββββββ βββββββββββββββββββββββββ
Say this: βItβs a classic three-tier architecture: React SPA, Express REST API, PostgreSQL database, deployed separately so each layer can scale independently.β
How to Draw It (2 Minutes on Whiteboard)
Draw these boxes left to right, then add arrows:
[Browser/React] ββHTTPSβββΊ [Express API] βββΊ [PostgreSQL]
β
ββββΊ [Redis] (if you use caching)
ββββΊ [S3/Cloudinary] (if file uploads)
ββββΊ [Socket.io] (if real-time)
Label arrows with protocol: REST JSON, WebSocket, SQL queries
Pro tip: Practice drawing this in under 60 seconds. Muscle memory matters in interviews.
Explaining Your Tech Stack Choices
Use the format: βI chose X because Y. Alternative was Z, butβ¦β
Frontend
| Choice | Good reason to give |
|---|---|
| React | Component reusability, large ecosystem, I know it best |
| Next.js | SSR for SEO, file-based routing, API routes in one repo |
| React Query | Server state caching, less boilerplate than Redux for API data |
| Tailwind CSS | Fast prototyping, consistent design system |
| Zustand | Lightweight global state without Redux complexity |
Backend
| Choice | Good reason to give |
|---|---|
| Node.js + Express | Same language as frontend, fast to build, huge npm ecosystem |
| PostgreSQL | Relational data with joins, ACID for transactions, free tier on Railway |
| MongoDB | Flexible schema for rapid prototyping, nested documents fit my data |
| Prisma | Type-safe queries, migrations built-in, great DX |
Deployment
| Choice | Good reason to give |
|---|---|
| Vercel (frontend) | Zero-config deploys, CDN, preview URLs per PR |
| Railway/Render (API) | Simple Node deploy, managed Postgres addon |
| Docker | Consistent environments, easy to hand off to teammates |
Architecture Patterns to Name-Drop (If Applicable)
| Pattern | When it applies | Example sentence |
|---|---|---|
| MVC | Routes β controllers β models | βExpress routes map to controller functions that call Prisma models.β |
| Middleware chain | Auth, logging, validation | βEvery protected route passes through auth middleware before the controller.β |
| Repository pattern | Abstracting DB access | βI wrapped all user queries in a UserRepository so controllers donβt touch SQL directly.β |
| Client-server | Any web app | βThin client β business logic lives on the server, frontend just renders and sends requests.β |
| Monolith | Single deployable app | βItβs a monolith β one Express app. Fine for this scale; Iβd extract a notification service if we grew.β |
Folder Structure (Show You Thought About Organization)
Frontend (Feature-Based)
src/
βββ components/ui/ # Reusable: Button, Modal, Input
βββ features/
β βββ auth/ # Login, Register, useAuth
β βββ dashboard/ # Dashboard-specific components
β βββ [feature]/
βββ hooks/ # Shared custom hooks
βββ lib/api.js # Axios instance, interceptors
βββ pages/ or app/ # Route entry points
βββ utils/ # Helpers
Backend (Layered)
src/
βββ routes/ # Route definitions
βββ controllers/ # Request handlers
βββ middleware/ # auth.js, validate.js, errorHandler.js
βββ models/ or prisma/ # Database schema and queries
βββ services/ # Business logic (optional layer)
βββ utils/ # Helpers, email templates
βββ config/ # DB connection, env vars
Interview line: βBackend is layered β routes define endpoints, controllers handle request/response, and Prisma handles all database access. Keeps concerns separated.β
Data Flow Example (Trace One User Action)
Practice narrating a complete flow. Example: User creates a post
1. User fills form in React β clicks Submit
2. React calls POST /api/v1/posts with JSON body + JWT in Authorization header
3. Express receives request
4. authMiddleware verifies JWT β attaches req.user
5. validateMiddleware checks title/body present
6. postController.create() called
7. Prisma: db.post.create({ data: { title, body, userId: req.user.id } })
8. Returns 201 { data: { id, title, body, createdAt } }
9. React Query invalidates 'posts' cache β feed refetches
10. UI shows new post at top of feed
This 10-step walkthrough impresses interviewers more than any diagram.
Scale Questions (Always Prep This)
βWhat breaks first at 10,000 users?β
Honest student answers:
- Database β unindexed queries slow down β add indexes, connection pooling
- Single server β CPU/memory maxed β horizontal scaling behind load balancer
- File uploads β disk fills up β move to S3/Cloudinary (if not already)
- In-memory sessions β lost on restart/multi-server β move to Redis
- No caching β repeated DB hits β Redis cache for hot data
βHow would you scale this?β
Current: [React on Vercel] β [1 Express server] β [1 Postgres]
10x: [React on Vercel] β [Load Balancer] β [3 Express servers] β [Postgres + Redis cache]
β [Read replica]
100x: Add CDN for assets, queue for async jobs (email), separate file service
Common Architecture Mistakes Students Make
| Mistake | What to say if true | Fix narrative |
|---|---|---|
Everything in one server.js | βStarted monolithic for speed" | "Iβd split into routes/controllers/servicesβ |
| No environment variables | βLearned this the hard way" | "Now all secrets in .env, .env in .gitignoreβ |
| Frontend calls DB directly | Never do this | N/A |
| No error handling middleware | βAdded after debugging production errors" | "Centralized error handler returns consistent JSONβ |
| CORS not configured | βFixed when frontend couldnβt reach API" | "Configured CORS for my Vercel domain onlyβ |
Turn mistakes into learning stories β interviewers respect growth.
Checklist: Can You Answer These?
- Draw your architecture in 60 seconds
- Explain why you chose each technology
- Trace one user action end-to-end (10 steps)
- Name what breaks first at 10x scale
- Describe your folder structure and why
- Identify one architectural decision youβd change
Next: authentication.md | database-design.md