Thank you for such an amazing video ! One request , Can someone explain more about the client side caching ? Does it mean that client(say chrome browser accessing Jira) queries TCS and stores the DB info, and sends it in each request ? Or client refers to a microservices receiving the request from an app or web browser ?
@Carmel Hinks : at @13:31, If we are still fine with eventual consistency for read then what was the need for single source of truth. I believe while writing data, you can set quorum and decide how many nodes should receive data before confirming write successful. Later all nodes will get sync data and have upto date information. In that way even write will also get performance improvement because write operation will also happen based on nearest datacenter. Please correct me if I have wrong understanding.
Wait, wait, wait. I'm making an assumption here, but they talked about "stateless" nodes. Then they put caching (which is storage of state), on each of the EC2 nodes requesting information from the database? Why not have a separate caching server, where any node can invalidate/ update the cache centrally? That should have gotten rid of the need for the SNS service and leaves the nodes stateless. And, btw.....we use Jira and it is slow. So..... whatever.
Thanks for sharing. very interesting. I am curious if anyway possible to only have cache at TCS side, no dynamo db. I.e (Catalog =dynamo+ec2) --> stream --> (Tcs=ec2 writing on cache)
How do I create architecture for azure appservice+functions with two same but separate databases that are in diffferent regions and should not be replicated. code base can be one or multiple, whats best option. Will it Azure front door in front of codebase with db in two different region or Will it be same code base with only db in two separate regions
In multi-tenant architecture how do we provide a certain feature to only a selected customer ? Acc. to me we can achieve this in single tenant by only upgrading a customer specific node..
With reference at 12:49. At 14:21, Why do we need to have a tool to sync data from single point of truth, write again and flush it back? Shouldn't Kinesis stream hold unread streams in its queue? and when Western EU is back online, start accepting messages inorder and save it?
Simply fantastic. Can you tell us more about your single tenant architecture ? How many customers were you able to serve with that arch? how did you upgrade these thousands of customers? how frequently did you upgrade? were you able to keep all of them on the same version? etc.
"single source of truth" imagine that. It's a good thing modern sensibilities regarding truth haven't infiltrated the computing world. yet. Good speech. I enjoyed it very much. I'm a total noob so it's refreshing learning about this without all the inside tech jargon. It's also quite refreshing hearing how it all came about and why. Thank you.
Hello Carmel, this video is probably one of those rare hidden gems where deep architectural insights are explained in the simplest manner possible.. kudos to you for sharing this... I do have a request - will it be possible for you to share the presentation slide deck
Best practices that you should consider for your Kubernetes multi tenancy SaaS application with Amazon EKS www.clickittech.com/saas/kubernetes-multi-tenancy/
Hello! Here's an amazing blog that talks about all the Multi tenant architecture environment. Hope it is useful for you! www.clickittech.com/saas/multi-tenant-architecture/
Awesome talk, I just made a paper about how to create a multi tenant architecture for a SaaS application on AWS: www.clickittech.com/saas/multi-tenant-architecture/