3 ms·

To give better context, we're building a new internal app, let's call it AppX. Let's say this app manages IMDB-like data. Many other apps in the org will need t

To give better context, we're building a new internal app, let's call it AppX. Let's say this app manages IMDB-like data. Many other apps in the org will need to use AppX. The vast majority of apps are probably used by a handful of people. If any external app with heavier traffic wanted to use AppX, we should architect it accordingly. Here is the full proposal: https://docs.google.com/document/d/e/2PACX-1vT5i_J8Kq2VEcyqdchKhF-ToaweSVUXk7PJgRDf8G99DJEDsfw2UwGKTeVAqAjr1tQPxhVglnScReVE/pub https://docs.google.com/document/d/e/2PACX-1vT5i_J8Kq2VEcyqd...

g-b-r 9mo ago
So, before sending a proposal I'd do everything possible to understand the reasons of the situation. You think you know who's responsible for it; just ask him You'll have a hard time at changing things without knowing the background of the situation. I realized that in the microservices world this kind of duplication could be acceptable; are those apps meant to be microservices? --- I disagree with the "data alone isn't valuable" paragraphs of your proposal; I was actually going to tell you to keep in mind DBMS, besides APIs: they're specifically built to provide data to many parties, efficiently and safely. One concern of allowing APIs might be that it might be demanding for an app, it could require adjustments and fine-tuning. Allowing direct access to a DBMS would largely avoid any such problem. You might well not even need any read replica, if you don't have an enormous load of requests (but you might prefer to make them, for redundancy and decoupling). Even some derived data could be handled by stored queries, although your team might not enjoy dabbling with sql too much. > This architecture was designed to achieve loose coupling, high availability, and independent deployability. These remain valuable goals that any proposed changes should preserve. Were you explicitly told that these were the goals? If so, it sounds a lot like microservices; data duplication and very strong decoupling is encouraged, and it could be hard to convince your colleagues. > Our current approach draws inspiration from event sourcing, Are you sure? A core aspect of data sourcing is storing all the events, and deriving the current state from them. It might be just an event-driven architecture. --- I agree with most of your document, anyhow, although it might be hard to convince the others, if they're all-in into microservices.

g-b-r 9mo ago

So, before sending a proposal I'd do everything possible to understand the reasons of the situation. You think you know who's responsible for it; just ask him You'll have a hard time at changing things without knowing the background of the situation. I realized that in the microservices world this kind of duplication could be acceptable; are those apps meant to be microservices? --- I disagree with the "data alone isn't valuable" paragraphs of your proposal; I was actually going to tell you to keep in mind DBMS, besides APIs: they're specifically built to provide data to many parties, efficiently and safely. One concern of allowing APIs might be that it might be demanding for an app, it could require adjustments and fine-tuning. Allowing direct access to a DBMS would largely avoid any such problem. You might well not even need any read replica, if you don't have an enormous load of requests (but you might prefer to make them, for redundancy and decoupling). Even some derived data could be handled by stored queries, although your team might not enjoy dabbling with sql too much. > This architecture was designed to achieve loose coupling, high availability, and independent deployability. These remain valuable goals that any proposed changes should preserve. Were you explicitly told that these were the goals? If so, it sounds a lot like microservices; data duplication and very strong decoupling is encouraged, and it could be hard to convince your colleagues. > Our current approach draws inspiration from event sourcing, Are you sure? A core aspect of data sourcing is storing all the events, and deriving the current state from them. It might be just an event-driven architecture. --- I agree with most of your document, anyhow, although it might be hard to convince the others, if they're all-in into microservices.