Neo System Design Lite

Neo System Design Lite

Opinionated system design for small teams that ship. No "it depends" — concrete defaults backed by production evidence.

Audience: 1-10 engineers, <100K users, pre-Series A startups, indie SaaS, side projects scaling up.

Philosophy: Complexity is a tax on velocity. Pay it only when data proves you must.

When to Use

• Building an MVP or early-stage product
• Making tech stack decisions for a small team
• Wondering "do I need X?" (the answer is usually no)
• Reviewing architecture for over-engineering
• Cost-optimizing infrastructure

When to Use neo-system-design (Full Version) Instead

• 10 engineers needing independent deployment

• 100K DAU with measured bottlenecks

• System design interview preparation
• Enterprise-scale architecture decisions
• Multi-region, compliance-driven requirements

The Golden Rules

Rule 1: Innovation Token Budget

Every team gets about 3 innovation tokens. Spend them on what makes your product unique, not infrastructure. — Dan McKinley, "Choose Boring Technology"

• Your core product differentiator — worth a token
• Your database — not worth a token (use PostgreSQL)
• Your deployment pipeline — not worth a token (use a PaaS)
• Your message queue — not worth a token (use a database-backed queue or cron)
• Your frontend framework — not worth a token (use what your team knows)

Rule 2: The Anti-Complexity Checklist

Before adding ANY infrastructure component, answer:

1. Do I have a performance problem right now? (measured, not imagined)
2. Have I confirmed the actual bottleneck?
3. Can I solve this with a bigger instance instead?
4. Is this the simplest solution that works?
5. Will I regret this complexity in 6 months when priorities change?

If you can't answer YES to #1 and #2, stop. You're over-engineering.

Rule 3: The Stack Doesn't Matter

Pieter Levels runs multiple $2-3M/year businesses on PHP + jQuery + SQLite on a single $40/mo VPS. Photo AI makes $132K/month on 14,000 lines of PHP. Stack Overflow serves ALL traffic on 9 on-premise servers running a monolith.

Your customers don't care about your architecture. Ship fast with what you know.

The Default Stack

For Solo / 1-3 Engineers

For 4-10 Engineers

Same stack, just upgrade to paid tiers as usage grows:

Real example: An API monitoring SaaS making $120K ARR with 180 customers runs on $45/month infrastructure (Vercel Pro $20 + Supabase Pro $25 + BetterStack free tier).

The Decisions (Opinionated)

Decision 1: Database

The Answer: PostgreSQL. Done.

Don't think about it. Don't evaluate alternatives. PostgreSQL handles your use case.

Evidence:

• OpenAI serves 800 million users on an unsharded PostgreSQL (1 primary + ~50 read replicas)
• A single 4-vCPU Postgres handles 1,000-10,000 QPS with proper indexing
• 100 million rows per table before partitioning becomes necessary
• Photo AI ($132K/mo) runs on SQLite — Postgres is more than enough for you

Where to host it:

PostgreSQL Scaling Ladder (exhaust each step before moving to the next)

Most apps never leave Step 2.

What You Don't Need

• MongoDB: Your data has consistent structure. Postgres handles it better.
• Redis: Optimize queries first. Postgres with indexes gives <10ms reads.
• DynamoDB: You don't have unpredictable traffic at 100K+ QPS.
• Cassandra: You don't have >100K writes/sec of time-series data.
• Sharding: OpenAI serves 800M users without it. You don't need it.
• Read replicas: Not until your optimized workload saturates the CPU (>60% sustained at peak).

PostgreSQL Can Replace (so you don't add infra)

Decision 2: Auth

The Answer: Use a Managed Service. Never Roll Your Own.

Authentication is the wrong place to demonstrate engineering creativity. A mistake in your auth implementation is a security incident.

Note: Auth.js (NextAuth) is in maintenance mode — the core team joined Better Auth in Sep 2025. Auth.js v5 never left beta. For new projects, use Better Auth or Clerk.

What You Don't Need

• Rolling your own auth: Never. Ever.
• OAuth complexity: Your managed service handles it transparently.
• SAML/SSO: Skip until an enterprise customer demands it.
• Multi-factor auth: Clerk/Better Auth include it. Don't build it.

Auth Decision by Scenario

Revisit Threshold

• 50K MAU: Evaluate cost. Clerk ~$0.02/MRU after free tier. Supabase ~$0.00325/MAU.
• First enterprise SSO demand: Add WorkOS (1M free MAU for basic, SSO is paid add-on).

Decision 3: Deployment

The Answer: PaaS First. VPS When Cost Matters. Never Kubernetes.

Cost Reality at Small Scale

What You Don't Need

• Kubernetes: A team of 3 spent $14,850/mo on K8s. Moved to Fly.io for $680/mo. "We were cosplaying as Google." K8s requires 3+ dedicated platform engineers to be manageable. You don't have that.
• AWS directly: $0 bill becomes $80 overnight. Use a PaaS until you outgrow it.
• Microservices deployment: You have one service. Deploy it.
• Blue-green / canary deployments: Nice in theory. At your scale, "deploy and watch Sentry" is your canary.

Revisit Threshold

• PaaS bill > $200/mo: Consider Hetzner VPS + Coolify ($7-20/mo equivalent).
• Need persistent processes (WebSockets, workers, cron): Railway or Fly.io (not Vercel).
• PaaS bill > $500/mo AND you have ops knowledge: Self-host (37signals saved $7M over 5 years leaving AWS, but they had dedicated ops staff).

Decision 4: Architecture

The Answer: Monolith. Extract Services Only With Proof.

The Over-Engineering Traps (Don't Fall In)

Trap 1: Premature Microservices

I watched a startup burn $500K building: 12 microservices (for a todo app), a 5-node K8s cluster (handling 50 requests/day), event sourcing with Kafka (for a CRUD app), a dedicated DevOps team (for 3 developers).

Trap 2: Kafka for CRUD

• If you have < 1,000 events/day → database-backed queue (pg_boss, BullMQ, Solid Queue)
• If you have < 100,000 events/day → still probably a database-backed queue
• Kafka is for millions of events/day with multiple independent consumers

Trap 3: Event Sourcing / CQRS

• 90%+ of applications need traditional CRUD
• Event sourcing is for financial/audit-critical workflows with regulatory requirements
• "Just use a database" is the right answer almost always

Trap 4: Premature Sharding

• OpenAI: 800M users, unsharded Postgres
• If you're planning to shard at 5M users, you're making an expensive mistake

The Modular Monolith Pattern

Structure your monolith well from day one — makes future extraction trivial:

src/
  modules/
    auth/          # Clear boundary
    billing/       # Own models, own services
    notifications/ # Explicit interface
    core/          # Shared utilities

• Separate packages/folders per domain
• Define explicit interfaces between modules
• Keep database schemas logically separate (same DB is fine)
• You get all organizational benefits of microservices with zero operational overhead

When to Actually Extract a Service (all must be true)

• You have measured evidence of a scaling bottleneck in that specific module
• The module has dramatically different scaling needs (e.g., 100x CPU for video processing)
• You have >10 engineers and deployment is blocking multiple teams
• You have the operational capacity to manage a distributed system (monitoring, tracing, debugging)

If you can't check ALL four, keep the monolith.

Decision 5: Caching

The Answer: You Probably Don't Need a Cache Layer. Optimize Queries First.

-- This query takes 5-20ms with proper indexes.
-- Redis would save 4-18ms. Not worth the complexity.
-- Add an index instead.
CREATE INDEX idx_posts_published_created ON posts (published, created_at DESC);

The Caching Ladder

Concrete Thresholds Before Adding Redis

You need 2+ of these simultaneously to justify Redis:

When Redis Actually Helps (if you do add it, use Upstash — serverless)

• Rate limiting in serverless environments (no persistent process for counters)
• Session storage across stateless function instances
• Background job queues (BullMQ) beyond what SKIP LOCKED provides
• Shared ephemeral state across multiple app servers

Decision 6: Security (Non-Negotiable Minimum)

Day 1 — Even at 0 Users

At 100+ Users (Month 1)

Skip Until Enterprise Customer / Series A

• SOC 2 / ISO 27001 audit: Implement good practices now, pay for the audit later ($15-40K)
• Penetration testing: Get one before Series A ($6-12K)
• WAF: Cloudflare free tier covers basics
• Bug bounty program: After you have a security team
• CSRF tokens: SameSite cookies handle most cases in modern browsers

Password Rules (if not using managed auth)

• Prefer passkeys (WebAuthn/FIDO2) — mainstream in 2026, phishing-resistant. Offer them as the default, password as fallback.
• NEVER store plain text or unsalted hashes
• Use bcrypt/scrypt/argon2 with unique random salt per password
• Minimum 12 characters, no maximum (within reason)
• Check against known breached passwords (HaveIBeenPwned API)

Decision 7: Monitoring

The Answer: Sentry + Uptime Check = $0/month

Setup (5 minutes)

1. npm install @sentry/nextjs && npx @sentry/wizard@latest -i nextjs
2. Add a /api/health endpoint that checks DB connectivity
3. Point BetterStack at your health endpoint
4. Done.

What You Don't Need (Enterprise Theater)

• Datadog ($300-800/mo for small teams): You don't need full-stack APM yet
• Full ELK stack: console.log with structured JSON + Axiom free tier
• Distributed tracing: You have one service. Nothing to distribute.
• Custom Grafana dashboards: Nobody will look at them
• PagerDuty: You're 3 people. A Slack webhook is your on-call rotation.

Monitoring Scaling Ladder

Decision 8: API Design

The Answer: REST. Keep It Simple.

At small scale, REST covers everything. Don't add GraphQL or gRPC until you have a measured reason.

REST Essentials (The Only Rules That Matter)

1. Use nouns for resources: /users, /posts, /orders
2. Use HTTP methods correctly: GET (read), POST (create), PUT (replace), PATCH (update), DELETE (remove)
3. Return proper status codes: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Server Error
4. Validate all input server-side: Zod schema → parse before any logic
5. Paginate list endpoints: ?page=1&limit=20 or cursor-based
6. Version from day 1: /api/v1/ — costs nothing, saves future pain
7. Consistent error format:

{ "error": { "code": "VALIDATION_ERROR", "message": "Email is required" } }

What You Don't Need

• GraphQL: Unless you have 3+ different frontend clients with very different data needs. Caching is harder. Tooling is more complex. REST + good endpoint design covers 95% of cases.
• gRPC: Unless you have internal service-to-service calls at >10K QPS. Browser can't call gRPC directly.
• WebSockets: Unless you're building chat, multiplayer games, or collaborative editing. For notifications, live feeds, AI streaming → use SSE (Server-Sent Events) first. Simpler, works everywhere.
• Webhooks infrastructure: Until you're a platform that external developers integrate with.

When to Add Real-Time

Server pushing updates to client (notifications, feeds, AI streaming)?
  → SSE (Server-Sent Events). One HTTP connection. Auto-reconnect built in.

Client AND server both sending frequent messages (chat, games)?
  → WebSocket. Full-duplex.

Server-to-server event notification (payment confirmation, CI/CD)?
  → Webhooks (HTTP POST with signature verification).

SSE covers 80% of "real-time" use cases. Start there. Escalate to WebSocket only when the client needs to send frequent messages.

The Graduation Checklist

You're ready for neo-system-design (full version) when 3+ are true:

• >10 engineers needing independent deployment
• >100K DAU with measured, confirmed bottlenecks
• Single PostgreSQL is actually at capacity (not "might be someday")
• Infra spend >$2K/month and needs optimization
• Monolith deploy >30 minutes and blocks multiple teams
• Different scaling needs across components (100x CPU for video, 1x for API)
• Regulatory requirements forcing architectural changes (multi-region, data residency)

If you can't check 3+ of these, you don't need Netflix-scale architecture.

Quick Reference Card

The One-Line Answers

Cost Targets

The Only Metrics That Matter Early On

1. Is the app up? (uptime monitor)
2. Is anything broken? (Sentry errors)
3. Are users using it? (PostHog / analytics)
4. Is it fast enough? (Core Web Vitals, check quarterly)

Everything else is enterprise theater until you have enterprise problems.