{"data":{"items":[{"id":"database-per-tenant","title":"Database-per-tenant sharding for a multi-tenant SaaS","company":"Kitchen 365","problem":"100+ client storefronts needed fully isolated data, without maintaining a separate fork of the codebase for each client.","design":["Directory-based sharding: a tenant directory resolves each request to that tenant's own database.","All traffic flows through one shared codebase and service architecture, deployed as a distributed system on Kubernetes."],"safeguards":["Cross-tenant data access — isolation is structural (separate databases), not a WHERE clause someone can forget.","Per-client drift — no forks, so every fix and feature reaches every tenant."],"outcome":"Per-client forks removed entirely; one platform serves 100+ storefronts.","stack":["NestJS","PostgreSQL","TypeScript","Kubernetes"]},{"id":"versioned-schemas","title":"Versioned schema management with zero-downtime onboarding","company":"Kitchen 365","problem":"With a database per tenant, schema changes must roll out across many databases that will not all be on the same version at the same time.","design":["A self-maintained shared library of common migrations, entities and DTOs used by every service.","Tenants can run concurrent schema versions; TypeORM rollouts are automated."],"safeguards":["Services and schemas drifting apart — entities, DTOs and migrations ship together from one library.","Downtime during onboarding — new tenants are provisioned without interrupting existing ones."],"outcome":"Zero-downtime tenant onboarding with automated schema rollouts.","stack":["TypeORM","PostgreSQL","TypeScript"]},{"id":"connector-framework","title":"Configuration-driven CRM & accounting connector framework","company":"Kitchen 365","problem":"Every client integration with a CRM or accounting system (Freshsales, QuickBooks) took days of custom work.","design":["A pluggable, distributed connector framework communicating asynchronously over Amazon SNS topics and SQS queues.","Onboarding a new client is a configuration change — no code."],"safeguards":["Coupling the storefront to third-party availability — integrations run asynchronously over queues instead of in the request path."],"outcome":"Client integration time cut from days to minutes.","stack":["AWS SNS","AWS SQS","Node.js","Freshsales","QuickBooks"]},{"id":"catalog-sync","title":"Master-to-tenant catalog sync","company":"Kitchen 365","problem":"A master catalog must flow to every tenant, but tenants customize their copies — a naive sync would overwrite their changes.","design":["Maps products, categories, attributes and inventory from master to each tenant.","Selective field updates plus reference tracking decide what may be overwritten."],"safeguards":["Clobbering tenant customizations on every sync."],"outcome":"Tenants receive master catalog updates while keeping their own customizations.","stack":["NestJS","PostgreSQL","TypeScript"]},{"id":"catalog-generation","title":"High-throughput catalog generation","company":"Kitchen 365","problem":"Large multi-tenant catalogs had to be generated and served without running out of memory or serving half-written files.","design":["Streaming JSON writes keep memory flat regardless of catalog size.","Atomic file swaps: write to a temporary file, then rename over the live one.","In-memory metadata caching avoids re-reading large files."],"safeguards":["Memory exhaustion on large catalogs.","Write race conditions — readers see the old file or the new one, never a partial write."],"outcome":"Large multi-tenant catalogs served without memory exhaustion or write races. (This site's message store uses the same temp-file + atomic-rename technique.)","stack":["Node.js streams","TypeScript"]},{"id":"magento-migration","title":"Migrating 23 clients off Magento","company":"Kitchen 365","problem":"Clients running on Magento had to move onto the new platform without breaking what they relied on.","design":["Built the platform with strong backward compatibility.","Reusable, shared components instead of per-client implementations."],"safeguards":["Breaking existing client behaviour during migration."],"outcome":"23 clients migrated; server and deployment cost reduced by 40%, with better maintainability.","stack":["NestJS","Next.js","PostgreSQL"]},{"id":"saas-billing","title":"SaaS subscription billing with Stripe","company":"Zerotime Solutions","problem":"An AI-powered product review generation platform (SerpAPI, OpenAI Assistants API, Supabase, Next.js) needed a dynamic recurring-subscription model.","design":["Stripe integration covering real-time upgrades and downgrades with proration.","Refunds and cancellations handled as first-class flows."],"safeguards":["Incorrect charges on mid-cycle plan changes — handled through proration."],"outcome":"A complete subscription lifecycle: upgrade, downgrade, proration, refund and cancellation.","stack":["Stripe","Next.js","Supabase","OpenAI Assistants API","SerpAPI"]},{"id":"feed-api","title":"Feed API for a social networking app","company":"Zerotime Solutions","problem":"A mobile app's feed needed to stay fast as its user base grew.","design":["Paginated feed API with location-based filters."],"safeguards":["Unbounded result sets — every response is paginated."],"outcome":"Response times kept low as the user base grew.","stack":["Node.js","Express.js"]}]},"meta":{"collection":"systems"}}