0

We are beginning to add third-party integrations that all have to do with a certain business concept. (If it helps to make things concrete, in our case it's "measurements," i.e. third-party partners that track whether customers have visited websites, downloaded apps, etc.)

Tech-wise, each of the third-party integrations work completely independently. Most of them require storing some metadata like API keys. One of them actually requires a new backend service because we need to write some business logic that orchestrates data via multiple GraphQL endpoints.

But because of this service's existence, a question has come up: Should we make this service into the "measurements service", housing all metadata there as well as the GraphQL orchestration for the one particular integration?

(If we weren't to do that, we would follow our current paradigm of storing metadata close to the accounts they're related to, in the accounts service.)

It seems natural to say, "Yeah, perfect, put all measurements-related stuff in one service over there." But is that a relevant reason? (I guess if developers wonder, "Where can I find metadata and logic related to measurements?" then it's all in this one repo?) It's possible future integrations will require us to build more "orchestration" endpoints, or require us to store more complex metadata, and we wouldn't want to create new services for individual integrations. On the other hand, it doesn't feel like a very principled approach to say, "Well, we need a new service for X anyway, so let's put Y and Z here too."

3
  • I don't think we can balance the trade-off for you. You already have a meta-data service for a reason and you know what is capable of. If the new service needs for meta-data is compatible with the existing service or not. You also know what's simpler / cheaper to do: refactor the meta-data + a new service or a single service with built-in meta-data management. No one but you (team and company) knows better what's more appropriate in the short, mid and long run. Both solutions are ok and both will be eventually deprecated, as the reality of the company and the market changes.
    – Laiv
    Jun 6, 2023 at 12:35
  • 2
    Microservices are a deployment solution, not a "how to organise source code" solution. Choices about how to organise code shouldn't affect how a system is deployed. And the way a system is deployed shouldn't affect how the code is organised (in particular, it shouldn't be related to developers' git/source code/project structure). Whether you want to keep all code related to measurements in one place, or want to break it up should be totally unrelated to whether you also happen to use a microservices deployment strategy. Jun 6, 2023 at 14:05
  • @BenCottrell - Hmm, yeah, that's what I was reading too (e.g. tanzu.vmware.com/content/blog/…). Jun 6, 2023 at 14:43

1 Answer 1

0

Modules

So 1970 but we haven't found a better way to organise logic yet.

If you have code and data that want to work together the best place to put them is in a module.

  • If part of the module doesn't care about another part of the module (low cohesion) the module can be broken up.
  • If two modules are so close you can't tell which one your working with (high cohesion) then they probably need to be merged.

Deployment

Well now that you, lets say 20 modules, you can choose how you want to bundle and deploy them. Maybe 5, 12, and 3 into three separate processes.

  • Maybe one process is dockerised. It doesn't matter to the modules.
  • Maybe two processes both include the same module (ie. database module). That's fine. Updates tend to be deployed dark these days anyway, once everyone has been redeployed. Turn the flag on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.