Modular Monoliths and gRPC: Building a Production Backend for €27/Month

A solo founder claims to run a multi-platform backend for €27 monthly. This analysis examines the two detailed architectural decisions: a modular monolith and gRPC with Bull for inter-service communication.

The author of a dev.to post claims to operate a production-ready backend supporting social media giveaways, a gift card marketplace, and telecom gift vending for €27 per month. This system, built by a solo founder, relies on specific architectural choices detailed in the post.

Three Services, Not Ten, Not One

The founder chose a modular monolith approach over a full microservice architecture. The backend is structured as a NestJS monorepo containing three independently deployable applications. These include a Giveaway API (handling events, participants, wallets), a Giftcard API (managing cards, merchants, escrow), and a Job Processor (dedicated to background tasks without an HTTP surface).

This design prioritizes independent deployability and separate connection pool scaling for distinct bounded domains. The founder argues that further splitting services—for authentication, notifications, or payments—would introduce coordination overhead without commensurate operational gains at this scale. The monorepo structure consolidates the build pipeline, migration runner, gRPC contract types, and test suite, aiming to reduce dependency management complexity while retaining organizational clarity.

gRPC for Internal Communication

Inter-service communication between the Giveaway API and Giftcard API uses gRPC instead of REST. The founder cites three reasons for this decision. First, gRPC enforces typed contracts at compile time via .proto files, which are compiled into TypeScript interfaces. This ensures that changes to request or response shapes in one service cause a compile-time failure in dependent services, preventing runtime errors. Second, gRPC facilitates bidirectional calls over an internal Docker network without authentication headers, CORS, or URL routing overhead.

The third reason involves a custom createQueuedGrpcService proxy that intercepts every gRPC method call. Instead of direct execution, the proxy enqueues a GRPC_CALL Bull job, serializing the service name, method name, and request payload into Redis. The Job Processor then picks up and executes the actual gRPC stub. This mechanism ensures that every gRPC call is persisted and retried through Bull, rather than relying solely on in-memory retries.

What We'd Change

The modular monolith approach, while effective for a solo founder targeting low infrastructure costs, introduces trade-offs for scaling teams or higher traffic. The shared PostgreSQL database and Redis instance, while cost-efficient, could become bottlenecks for independent scaling or introduce complex schema evolution challenges across services. As team size grows, the monorepo's shared build and test pipelines, while initially beneficial, can slow down development cycles if not managed with strict code ownership and review processes.

The gRPC with Bull queue for all inter-service communication is a sophisticated pattern for reliability, but it adds significant complexity. For a system operating at a €27/month scale, the operational overhead of managing Bull, Redis, and a custom gRPC proxy might outweigh the benefits of compile-time type safety and persistent retries. Debugging distributed systems with queued calls is inherently more challenging than direct HTTP requests. This architecture decision, while technically sound for specific reliability needs, may be over-engineered for many early-stage or bootstrapped products, increasing initial development time and ongoing maintenance burden.

Landing

The founder's architectural choices demonstrate a deliberate trade-off: investing in upfront complexity for long-term reliability and cost efficiency. The modular monolith with gRPC and a persistent queuing layer aims to provide a robust foundation for multiple product lines on minimal infrastructure. This approach highlights that strategic technical debt and architectural sophistication can coexist, provided the founder understands the specific constraints and future scaling vectors of their product portfolio.

The investor read

This signal demonstrates a bootstrapped founder's focus on extreme cost efficiency (€27/month infrastructure) while implementing a sophisticated backend architecture. The modular monolith approach, combined with gRPC and a persistent queuing layer, signals a deliberate choice to build for reliability and future extensibility without venture capital. For investors, this indicates a founder capable of deep technical execution and resourcefulness. While not directly comparable to venture-backed SaaS benchmarks, it highlights the potential for highly capital-efficient product development in niche markets. The complexity of the architecture, however, suggests higher initial development costs and potential scaling challenges if the product achieves significant growth requiring larger engineering teams or more aggressive feature velocity.

Pull quote: “The founder argues that further splitting services—for authentication, notifications, or payments—would introduce coordination overhead without commensurate operational gains at this scale.”