Building a SaaS product that holds up as it grows
Tenant data separation, caching and when (and when not) to split your app into services.
By Nivra Technologies··7 min read
Keeping each customer's data separate
Every SaaS product has to keep one customer's data away from another's. There are three common ways to do it: a separate database per customer, one database with a separate schema per customer, or shared tables where every row is tagged with the customer it belongs to.
Separate databases give the strongest isolation, which some larger or regulated customers will ask for. For most products, shared tables with row-level security are cheaper to run and much easier to update.
Take the load off the database
Once traffic grows, the database is usually the first thing to struggle. A cache like Redis helps by storing the results of common, slow queries.
User profiles, settings and catalogue data are good candidates, because they're read constantly and change rarely. Caching them can take a lot of pressure off the database during busy periods.
Split things up only when it hurts
Microservices get a lot of attention, but for an early product, a single well-organised codebase is usually faster to build and easier to run.
Split out a piece when there's a clear reason. Maybe report generation is slowing everything else down, or payments need to be isolated and deployed on their own. Then a problem in one area can't take down the rest.
Planning something similar? Tell us about your project or read more articles.