It’s time to talk about the types of things you should consider when diving into multi-tenant applications and things to be especially aware of if you attempt to make things faster by going multi-threaded at the same time. Join us as Allen continues is non-winning / non-losing streak, JZ is taken out by a storm, and Outlaw continues to ignore the notes for the intro to the show…
News
Reviews
Upcoming Events
Atlanta Dev ConSeptember 7th, 2024https://www.atldevcon.com/)
DevFest Central Florida on September 28th, 2024https://devfestflorida.com/)
Episode
Single vs multi-tenanted applications and multi-threaded programming
Be very careful about sharing state when doing anything in multi-threaded AND multi-tenanted applications
What are some important things to consider when writing multi-tenanted applications – per Claude)
As mentioned in the episode, Claude’s answers seem to be very database heavy
Data isolation: Ensure that each tenant’s data is securely separated and inaccessible to other tenants.
Authentication and authorization: Implement robust systems to verify tenant identity and control access to resources.
Scalability: Design the architecture to handle growth in both the number of tenants and data volume per tenant.
Performance: Optimize database queries and resource allocation to maintain speed as tenant count increases.
Customization: Allow for tenant-specific configurations and features without compromising the core codebase.
Monitoring and logging: Implement comprehensive logging and monitoring to track usage, errors, and performance per tenant.
Maintenance and updates: Design the system to allow for updates and maintenance with minimal disruption to tenants.
Data backup and recovery: Implement tenant-specific backup and recovery processes.
Compliance and data regulations: Ensure the system can meet various regulatory requirements that may differ by tenant.
Tenant onboarding and offboarding: Create efficient processes for adding new tenants and removing old ones.
Good feature flagging support?
Tracing / OpenTelemetry
**Can you elaborate on the data isolation?**Data isolation is crucial in multi-tenant systems to prevent unauthorized access and ensure data privacy. Here are some key strategies to ensure data isolation:
Separate databases
Use a separate database for each tenant
Pros: Strong isolation, easier compliance
Cons: Higher maintenance, potentially higher costs
Shared database with separate schemas
Each tenant gets their own schema within a shared database
Pros: Good isolation, more cost-effective than separate databases
Cons: Requires careful access control, potential for errors
Shared schema with tenant ID
Use a single schema but include a tenant ID column in each table
Pros: Most cost-effective, easiest to maintain
Cons: Highest risk of data leaks, requires vigilant query filtering
Row-level security
Implement database-level security policies to restrict access based on tenant ID
Particularly useful with shared schema approach
Encryption
Encrypt sensitive data, potentially using tenant-specific keys
Adds an extra layer of protection even if other measures fail
Connection pooling
Use separate connection pools for each tenant to prevent session mixups
Query filtering
Always include tenant ID in queries, preferably at the database level
Use ORMs or query builders that automatically add tenant filters
API and application-level checks
Validate tenant ID in all API calls and application logic
Implement middleware to enforce tenant-specific access
Resources / Mentions
Salable Postgres product – Citushttps://www.citusdata.com/)
Envelope encryption if you’re wanting to use tenant specific keys for multi-tenanted encryption – one approach is envelope encryptionhttps://en.wikipedia.org/wiki/Hybrid_cryptosystem#Envelope_encryption)https://cloud.google.com/kms/docs/envelope-encryption)
OWASP multi-tenant or “Cloud Tenant” Isolationhttps://owasp.org/www-project-cloud-tenant-isolation/)
C#’s Parallel.ForEach method – the easy way to do parallel processing in C#https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.parallel.foreach?view=net-8.0)
Can’t remember why we linked episode 11, but here it is)
Tips of the Week
Speculative fix? If you’re not sure that your fix is going to work, or you can’t reproduce the problem then consider over-communicating it and keeping artifacts such as screenshots of what you attempted.
It’s useful for communication, but also for looking back when and if you start second guessing yourself.
Shapez 2 is a cool refactoring, automation, and puzzle game. It’s similar to Factorio, but with a heavier emphasis on refactoring and puzzles.https://store.steampowered.com/app/2162800/shapez_2/)
Kotlin – measureTimeMillishttps://kotlinlang.org/api/latest/jvm/stdlib/kotlin.system/measure-time-millis.html)
Google skills – learn and get certified in Google Cloud https://www.cloudskillsboost.google)
Pay for a year’s worth of training for $299 and get $200 towards a certification – over $1,500 value https://www.cloudskillsboost.google/payments/new) https://www.cloudskillsboost.google/subscriptions)
From Ivan Kuchin – Dasel – like JQ except it does JSON, YAML, TOML, XML and CSV with zero runtime dependencieshttps://github.com/TomWright/dasel)
Google Cloud products in 4 words or lesshttps://cloud.google.com/blog/topics/developers-practitioners/back-popular-demand-google-cloud-products-4-words-or-less-2022-edition)https://googlecloudcheatsheet.withgoogle.com/)