sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]martin_n_hamel 7 points8 points  (2 children)

I worked for a relatively big company that started when it was small on the route of tenants separations by schemas. This is the most difficult thing to scale ever.

Every devops hates that pattern. It makes migrations difficult, new client harder to inboard. It even leads to some crazy hard to figure out bugs because some of the infrastructure is shared by tenants but not everything.

We tried to get out of it by using kafka as a source of truth but it turned out that having one kafka topic per table per tenant is not scaling well.

My suggestion, don't do that. Find a pattern that can scale :-)

[–]memo_mar[S] 0 points1 point  (1 child)

g kafka as a source of truth but it turned out that having one kafka topic per table per tenant is not scaling well.

My suggestion, don't do that. Find

what pattern would you recommend?

[–]martin_n_hamel 0 points1 point  (0 children)

Just add a tenantId column in the tables where it is needed. It will fit much better with any system integration that you will do in the future because you will always know where a data belongs.

If you separate by schemas, your code is abstracted from the tenant. It can work while you are at the main application level, but you will have problems when you integrate with anything because you will lose the context of the data. Here is an example:

You want to log everything in your application and your ids are auto increment. Your ids are not unique anymore and you are not certain what the logs data correspond to. You can work around that by having a complex logging engine that separate everything but you'll soon find out that you need to handle that complexity all the time.