8

Multi-tenant systems seem more complicated to develop, but are vastly easier to manage and are much more flexible. In principle, it is easy to have multiple “databases”. More precisely, it is easy to have multiple schemas/namespaces on one database server. In practice, this complicates stuff a lot. For example, you might have separate connection strings for ...


3

When building event driven systems, events might be used for two distinct aspects of the system: for communication between components, e.g. using a message queue for representing the state of a service These concerns are related, sometimes intertwined, but often technically distinct. Infinite retention of an event stream would typically mean that you store ...


3

To solve the question of how Google Docs works: Here is a Blog post by the guy who designed the syncing system of gdocs: https://neil.fraser.name/writing/sync/ The link point to a detailed writeup of a syncing system that can work in lossy enviroment like Internet. The whole process is just a giant diff-match-Patch cycle between clients and the Server farm(...


2

It is indeed a confusing question: very often the decomposition into microservices (which would be Krutchen’s development view) is guided by the domain model (the logical view) and at a very granular level, so that both are completely aligned. Keep in mind however that this alignment is more a result of some specific choices and there are many more ...


2

To simply fix the issue at hand (data retention needs to be increased) one alternative is switching to service that allows for infinite retention (say Apache Kafka), however be aware that one day might run out of resources / maintaining this amount of resources would be too costly. The other is analogous ot tiered storage - the last X days are easily ...


2

You've misunderstood the article You've taken "multi-tenant" to mean "an application which is used by more than one tenant". I'm actually on your side here and I interpret multi-tenancy the same way, but the article uses a slightly different definition, which you seem to have missed. In the article, and I admit I agree they should've ...


2

The key requirement in multi-tenancy is that you can add additional tenants at run-time. If you want to have a separate database per tenant, you will have to devise some scheme to provision a database server, or at least a database instance, while the application is running, automatically, without developer intervention. Once the database instance is added, ...


1

Couple of things. First, decomposing the monolith isn't just about having microservices that exist in a vaccuum. Many services before this (BFF-style) were hand-rolling their orchestration. Instead, federation allows us to not hand-code BFFs from scratch by offloading the orchestration logic into a statically validatable schema. Now, we can have a plethora ...


1

The joins required for a SQL query are usually driven by the use case. You could end up with one repository method per use case, which would result in a large number of methods that are only called once or twice in the application. While there is nothing wrong with this, it does tend to make for cluttered and unorganized data access code. There is no general ...


1

This a pretty simple question with a pretty simple answer. No real "discussion" is necessary. Looking at the image on Mr. Martin's blog entry you will see that all external data comes from the Frameworks and Drivers layer. Whether it's stored in a DB or entered by the user through the UI, pulled in from an external device or whatever. The data ...


1

TL;DR: IMHO, debug code has no place in production code. Debug code is, as per its name, code to help you debug your program. That level of debugging should be completed before the product is shipped. Equally, any form of error message in production use should be sufficient to inform support, but be opaque enough that an user doesn't really know what it ...


Only top voted, non community-wiki answers of a minimum length are eligible