Why a Proven 6-Service Build Makes Cloud SaaS Effortless

Building a production-grade cloud storage SaaS is not just a coding challenge. It is a systems design challenge, a DevOps challenge, and an authorization challenge all at once. My Floppy, a cloud storage SaaS platform built by the Madgical Techdom engineering team, proves what is possible when you choose right over easy. Six independently deployable microservices, sub-100ms full-text search, and enterprise-grade identity federation — all delivered for a confidential media technology client, currently in private beta.
This is the technical breakdown.

The Problem: Why Cloud Storage SaaS Projects Fail

Most engineering teams underestimate what a cloud storage SaaS actually requires. The surface looks simple. The depth is not. Here are the four hard problems that derail teams before launch.

Authorization at scale – File-level permissions across users, teams, and organizations demand more than simple role-based access control. The permission model must survive complexity without degrading in performance.
Offline-first mobile – Users expect their files available without connectivity. Sync conflict resolution, when connections restore, is non-trivial at any scale.
Full-text search performance – Returning results in under 100 milliseconds across millions of documents requires deliberate index design. Installing Elasticsearch is not enough.
Enterprise identity and microservices coherence – B2B customers need SSO and multi-tenant isolation. Running multiple services introduces distributed system complexity. Service discovery, inter-service authentication, and consistent failure handling add significant engineering overhead.

The Solution: 6 Microservices, Each Built for a Purpose

The My Floppy architecture solves each problem with a dedicated service. No compromise. No deferred complexity.
React Native Mobile App
First, the mobile layer. The storage-system app uses the Ignite boilerplate on React Native with TypeScript. It handles folder management, file operations, and sync conflict resolution for offline edits. Maestro E2E test automation covers all critical user flows. The app ships on iOS, Android, and Web.
NestJS User Service Template
Next, the foundation every other service builds on. The user-service provides a standardized NestJS microservice template, including Swagger documentation, Winston structured logging, and an auth client for inter-service communication. New services scaffold from this template in minutes, not days. The result is an 80% reduction in new service setup time.
SpiceDB File Service
Subsequently, the toughest authorization problem gets its own service. The file-service integrates SpiceDB, a Google Zanzibar-inspired permission engine, for every file operation. Before any read, write, share, or delete executes, the request passes through a centralized permission graph. PostgreSQL stores file metadata. The authorization model handles unlimited permission complexity without performance degradation.
Elasticsearch Search Service
Furthermore, search requires a purpose-built service. The search-service uses NestJS with Elasticsearch, supporting index creation, document CRUD, bulk operations, and full-text search. The index design delivers sub-100ms query times at millions of documents.
Centralized Notification Service
In addition, notifications are consolidated in a single service. The notification-service handles delivery across email, push, and in-app channels. One service, all channels, all platform services.
Keycloak Identity Provider
Finally, enterprise identity gets its own dedicated layer. Keycloak provides centralized SSO across all services via OAuth 2.0 and OIDC. B2B customers federate through Keycloak using their own identity provider, whether Azure AD, Okta, or Google Workspace. Multi-tenant isolation is enforced at the identity layer.

Technical Architecture of the Cloud Storage SaaS
The complete technology stack for My Floppy:

Mobile: React Native, Expo, Ignite boilerplate, TypeScript, Maestro E2E testing
Backend services: NestJS, TypeScript, PostgreSQL, Elasticsearch, SpiceDB
Identity: Keycloak, OAuth 2.0, OIDC
Caching: Valkey, a Redis-compatible open-source cache
Infrastructure: AWS ECS, EC2, Terraform IaC, Karpenter, EKS
CI/CD: Self-hosted GitHub Actions runners, SonarQube quality gates
Frontend, B2B and B2C: React, TypeScript

Deployment is flexible by design. All components are self-hostable with no external SaaS dependencies. The architecture supports public cloud, private cloud, or on-premise data center deployments for clients with data sovereignty requirements.

Before vs After: What the Architecture Delivered

No standardized service template; each microservice required days of setup from scratch
File permissions managed at the application layer, creating growing authorization debt
Search relying on basic database queries, unable to scale to document volumes
No centralized identity; each service managing its own authentication

After:

6 independently deployable microservices, each scalable in isolation
Sub-100ms full-text search confirmed at millions of documents
SpiceDB handling fine-grained, per-file, per-user, per-organization permissions without performance cost
Keycloak providing enterprise SSO ready for B2B federation on day one
80% reduction in new service setup time via the standardized user-service template
SonarQube quality gates enforced across all 6 services from day one
Offline-first mobile with sync conflict resolution
Architecture deployable on public cloud, private cloud, or on-premise

Why This Cloud Storage SaaS Architecture Works

The decisions here are not creative. They are correct. SpiceDB exists because Google-scale authorization problems require Google-scale solutions. Keycloak exists because bolting auth onto a microservices platform always creates gaps. Elasticsearch with deliberate index design exists because search performance at document scale is an engineering problem, not a configuration problem.
Moreover, the standardized user-service template compounds in value over time. Each new service starts production-ready. The team does not rediscover the same setup challenges repeatedly. Consequently, velocity increases as the platform grows, not the reverse.
Our agentic AI and product engineering services follow the same principle. Right choices, made once, compounding forward.

Who Should Build a Platform Like This

This architecture is the right fit for:

SaaS founders building B2B or B2C cloud storage products requiring enterprise-grade authorization
Engineering teams that have outgrown monolithic authorization and need Google Zanzibar-style permission models
Product companies targeting enterprise customers who will require SSO, OIDC, and identity federation
Organizations with data sovereignty requirements needing self-hostable, cloud-agnostic infrastructure
Teams preparing for scale who want sub-100ms search performance designed in from the start, not retrofitted

Conclusion

My Floppy started as a single question: can a team build a complex, multi-service SaaS product from zero to production-grade without a client specification to hand-hold the process? The architecture answers that question. Six microservices. Enterprise SSO. Sub-100ms search. Google Zanzibar-inspired authorization. Offline-first mobile. All of it production-grade from day one.

You can see the full scope of what Madgical Techdom has built across the portfolio. Every engagement follows the same standard: right choices,

Interested in building a production-grade cloud storage SaaS for your team?
Book a free consultation