Monolith vs Microservices: Why I Chose a Modular Monolith for Nexural

The Nexural ecosystem has 7 interconnected systems: trading dashboard, Discord bot, research engine, alert system, newsletter studio, strategy tracker, and automation suite.

It would be natural to assume this is a microservices architecture. It's not. It's a modular monolith — and that was deliberate.

The Decision Framework

I asked three questions:

1. How many engineers? One (me). Microservices multiply operational overhead. With one engineer, every new service means another deployment pipeline, another monitoring setup, another failure mode to debug at 2am.

2. Do the modules need independent scaling? Not yet. The trading dashboard and research engine both run on Vercel. They don't have different scaling profiles that would justify separate infrastructure.

3. Do the modules need different tech stacks? Partially — the Discord bot is Node.js, the alert system is .NET. Those are separate services by necessity. But the web apps are all Next.js/TypeScript and share types, utilities, and database access.

What "Modular Monolith" Means in Practice

The codebase is organized as one repo with clear domain boundaries:

nexural/
├── domains/
│   ├── trading/        # Dashboard, instruments, positions
│   ├── research/       # Strategy analysis, metrics, reports
│   ├── community/      # Discord integration, moderation
│   ├── billing/        # Stripe subscriptions, invoices
│   ├── analytics/      # Telemetry, user behavior, KPIs
│   └── notifications/  # Alerts, emails, newsletters
├── shared/
│   ├── auth/           # Authentication, session management
│   ├── db/             # Database client, migrations, RLS
│   └── types/          # Shared TypeScript types
└── services/           # External service integrations
    ├── stripe/
    ├── alpaca/
    └── discord/

Key rules:

• Domains never import from each other directly — they communicate through the shared layer
• Each domain owns its own database tables (no cross-domain table access)
• Types are shared but business logic is not
• The API layer is thin — it calls domain functions, doesn't contain logic

What I'd Split Off (and When)

Two modules are candidates for extraction:

Discord Bot → Separate Service (already done) The bot runs on a different runtime (Node.js vs Next.js on Vercel). It needs persistent connections (WebSocket to Discord). It was the first thing I extracted. It runs on a VPS with PM2.

Alert System → Separate Service (when scale demands it) The alert system polls market data every second and evaluates 100+ price conditions. When the number of active alerts exceeds 1,000, the polling loop will need its own compute. That's when I'd extract it.

Everything else stays together until there's a genuine scaling or team reason to split. "We might need microservices someday" is not a reason.

The Deployment Advantage

One repo means:

• One CI/CD pipeline (not 7)
• One set of environment variables (not 7 .env files)
• One place to search for bugs
• Type safety across domain boundaries (try getting that with microservices)
• Atomic migrations (update schema + code in one deploy)

When Microservices ARE the Right Call

I'd choose microservices when:

• Multiple teams own different services (organizational boundary)
• Genuinely different scaling needs (one service handles 10K req/s while others handle 10 req/s)
• Different deployment cadences (one service deploys hourly, another quarterly)
• Fault isolation is critical (one service crashing can't take down the whole platform)

For a solo engineer building a product? Modular monolith, every time.

The Lesson

Architecture decisions should be driven by constraints, not trends. My constraint was being a solo engineer who needed to ship fast without operational overhead. A modular monolith lets me move at startup speed with enterprise code organization.

When Nexural has 5 engineers and 50K daily active users, I'll split services. Until then, the monolith ships faster.