How I Built a Multi-Asset Investment Platform with Next.js, PostgreSQL, Docker and AI

Overview

ApexPulse is a multi-asset investment dashboard designed to unify assets from multiple providers including Binance crypto holdings, Trading 212 stocks and ETFs, Nigerian Stock Exchange (NGX) positions, various currencies and pricing sources, AI-generated market signals, and automated portfolio updates. Rather than forcing every data provider into the UI directly, the platform is built as a modular monolith with clearly defined responsibilities.

Technology Stack

The core application runs on Next.js 15 + TypeScript, while PostgreSQL and Prisma provide the shared data layer. Docker ensures consistent local and production environments, and Redis is used for caching and rate limiting. Additional components include:

• NextAuth v5 for authentication
• TanStack Query for client-side caching and refresh
• OpenAI with DeepSeek fallback for AI signals
• Resend + React Email for daily briefs
• GitHub Actions for workflow automation and optional scheduling

Pricing Engine & Data Flow

A dedicated pricing engine routes each holding to its correct source:

• Crypto → Binance US stocks → Yahoo Finance
• Trading 212 → synced broker data
• NGX → Mansa API with scraper fallback

All prices are normalized internally into USD, providing a single consistent pricing model across the entire dashboard.

Background Processing

A separate cron worker handles non-user-triggered operations:

• Synchronises Binance holdings automatically
• Builds market snapshots
• Generates AI swing signals
• Applies an 80%+ confidence threshold
• Stores qualified signals in PostgreSQL
• Sends daily portfolio intelligence through Resend

For deployment flexibility, GitHub Actions serves as an alternative scheduling mechanism, allowing automated jobs to run independently of the main application process.

Resilience & Failure Handling

Financial APIs are unreliable-providers may become rate-limited, return incomplete data, or temporarily fail. To handle this, ApexPulse treats external price providers as best-effort dependencies. When a live quote cannot be retrieved, the system falls back to the holding's existing cost basis instead of returning zero, removing the asset, or breaking the dashboard. This ensures availability does not depend entirely on a single external API.

Architectural Choice: Modular Monolith vs. Microservices

The author deliberately avoided immediate migration to microservices. At this stage, a modular monolith provides:

• Clear domain separation
• Simpler deployment
• Lower operational complexity
• Shared transactional data
• Easier local development
• A clear path to split services later if scaling requirements demand it

Infrastructure such as Redis, managed workers, queues, and further service separation can be introduced only when there is an actual scaling requirement, avoiding premature infrastructure addition.

Public Project & Feedback

The implementation is publicly available at https://github.com/bhoyee/ApexPulse. The author invites feedback from engineers working with distributed systems, fintech platforms, backend architecture, or cloud infrastructure, specifically asking which architectural component would be prioritized for separation if significant scaling were required.

---

Tags: #SystemDesign #NextJS #FinTech #CloudEngineering