Architecting Full Stack Applications

When given a feature or system request, work top-down through the stack:

1. Clarify the requirement in business terms (who uses this, what problem does it solve, what's the scale?)
2. Sketch the data model first — entities, relationships, access patterns
3. Choose the architecture pattern (monolith/microservices/serverless) based on team size, scale, and time-to-market
4. Define the API contract before writing implementation
5. Build backend → frontend → wire together
6. Add auth/security, tests, and CI/CD — never as an afterthought

Example prompt response pattern:

Request: "Add a commenting feature to blog posts"

1. Data model: comments table (id, post_id FK, user_id FK, body, parent_id nullable for threading, created_at)
   - Index on post_id, parent_id for fast retrieval
2. Architecture: fits existing monolith, no new service needed
3. API: POST /api/posts/:id/comments, GET /api/posts/:id/comments?cursor=, DELETE /api/comments/:id
4. Backend: validation, rate-limiting, ownership check on delete
5. Frontend: optimistic UI update on submit, paginated/threaded render
6. Security: sanitize body (XSS), auth middleware, ownership-based RBAC
7. Tests: unit (validation, permissions), integration (API round-trip)

Use this checklist for any non-trivial feature or system design task:

Progress:
- [ ] Requirements clarified (business goal, users, scale, constraints)
- [ ] Data model designed (schema, relationships, indexes)
- [ ] Architecture pattern chosen and justified
- [ ] API contract defined (endpoints, payloads, error shapes)
- [ ] Backend logic implemented (business rules, validation, async handling)
- [ ] Frontend built (components, state management, accessibility)
- [ ] Security applied (auth, RBAC, input sanitization, encryption)
- [ ] Performance checked (query plans, bundle size, caching)
- [ ] Tests written (unit + integration, edge cases)
- [ ] CI/CD & deployment path confirmed
- [ ] Docs/handoff notes for team

Don't skip steps even under time pressure — flag shortcuts explicitly (e.g., "skipping RBAC for MVP, tracked as tech debt in ticket #123") rather than silently omitting them.

Example 1: Database schema design Input: "We need to store users, orders, and products. Users can have many orders, orders have many products." Output:

SQL
-- Normalized relational schema
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email VARCHAR(255) UNIQUE NOT NULL,
  password_hash TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE products (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name VARCHAR(255) NOT NULL,
  price_cents INTEGER NOT NULL CHECK (price_cents >= 0)
);

CREATE TABLE orders (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  status VARCHAR(20) NOT NULL DEFAULT 'pending',
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE order_items ( -- junction table for many-to-many
  order_id UUID REFERENCES orders(id) ON DELETE CASCADE,
  product_id UUID REFERENCES products(id),
  quantity INTEGER NOT NULL CHECK (quantity > 0),
  PRIMARY KEY (order_id, product_id)
);

CREATE INDEX idx_orders_user_id ON orders(user_id);
CREATE INDEX idx_orders_status ON orders(status);

Rationale: junction table avoids duplication, foreign keys enforce integrity, indexes support the most common query paths (user's orders, filtering by status).

Example 2: Architecture pattern choice Input: "Small team of 3, MVP for a B2B SaaS, need to launch in 6 weeks." Output: Monolith (e.g., Laravel or Node/Express with a single deployable). Justification: microservices add operational overhead (service discovery, distributed tracing, multiple deploy pipelines) that a 3-person team can't afford pre-product-market-fit. Structure the monolith with clear module boundaries (domain folders) so it can be split later if needed.

Example 3: Performance diagnosis Input: "Dashboard page takes 4s to load." Output:

1. Check network tab — is it one slow request or waterfall of many?
2. If DB-bound: run EXPLAIN ANALYZE on the query; look for seq scans, missing indexes, N+1 queries.
3. If N+1: replace with eager loading/JOIN or a batched dataloader.
4. If frontend-bound: check bundle size, lazy-load non-critical components, check for unnecessary re-renders (React DevTools profiler).
5. Add caching (Redis for hot queries, HTTP caching headers for static data) if the data doesn't change per-request.