0

I am trying to understand when does it make sense to have independent layers versus merging layers together.

For example, let's say there is a wallet service where you can keep money in separate buckets like food, household, electricity, travel. Money can be redeemed across multiple buckets as well, for example if sufficient balance is not available in food, redeem from household but other way it is not allowed.

Approach 1 to have 2 independent micro services like below

  1. Wallet service: Maintains balance against some bucket. With no redemption rules.

  2. Redemption service: Wrapper around account service, it understands rules like

    a. multiple buckets and hierarchy among different buckets.

    b. only allow X% redemption from particular bucket.

    c. only allow Y% redemption from particular buckets in a day.

    No one calls account service directly but only the wrapper service.

In Approach 2 We merge the micro services in a single one, and separate the accounting and redemption modules.

Here are some tradeoffs I can think of

In approach 1, Any redemption operation would require taking a lock in service 2 as well. Since all the redemption operation first depends on getting the current wallet information. Calculate the redemption operations to be performed across different buckets. then making another call to wallet service. So from execution perspective both the services are coupled for any redemption operation they perform. The benefit is that wallet and account services can be scaled independently.

In approach 2 If there are multiple use cases for wallet service. Few of them might require hierarchy across wallets, some of them may not require hierarchy or some of them may only allow x% of wallet to be consumed in a day. By clubbing all these logics together in the same service we will end up having wallet service catering to different concerns. The latencies would be lower in approach 2.

For now the approach I am thinking is to start with approach 2 and then move to approach 1 if enough diverse use cases are there.

Are there other tradeoff to be considered which can be deciding factor?

Improve this question
3
  • how about the bloat in code because of multiple different redemption logics? I too am not in favour of micro service after writing pros and cons. but just trying to understand if there are missing tradeoffs.
    – best wishes
    Commented Feb 6 at 9:25
  • 1
    It is generally always possible to segregate code without separating processes - most languages have plenty of tools which should allow splitting functionality into different modules, namespaces, etc; and even if the programming language does not have this, you can achieve a great deal of separation simply by enforcing a good directory/folder structure, and ensuring that the different "slices" are already separate in the overall project structure (possibly in source control too?). Furthermore, strong unit testing around each slice should be able to reinforce that modularity.
    – Ben Cottrell
    Commented Feb 6 at 9:31
  • putting the questions differently, when would it make sense to have 2 separate service than 1.
    – best wishes
    Commented Feb 6 at 10:19

1 Answer 1

Reset to default
2

The key thing here is:

No one calls account service directly but only the wrapper service.

If nothing calls the account/wallet service, then it doesn't need to be exposed as its own microservice.

Scaling doesn't really come into it because there's no harm in scaling a combined service over scaling part of a split service, you just have extra code on all the boxes.

Now, If you introduce a second Redemption service, say you have home and corporate customers with different logic. Then you have two services calling the same underlying Account Service, and it starts to make sense to split them up.

You still have the problem of the distributed lock, which I think you will need to solve first before splitting. But this seems to me to be a problem in both scenarios. If you have any sort of user interaction:

  • lock account
  • Get proposed split
  • check with user
  • apply redemption
  • release lock

That's keeping the lock open far too long and is a potential source of problems.

Improve this answer
4
  • yes, the question is when we have home and corporate customers with different logic.. Even then, are tradeoffs in the favour of having different service or merging the logic.
    – best wishes
    Commented Feb 6 at 10:26
  • 1
    it really starts to depend on the details, How big are the modules, how performant, is deployment becoming hard, do you expect more in the future, does one part of the service get more updates than the others etc etc. In my experience there isn't much of a performance hit in the extra microservice call in an environment where you are already making various over the network calls. Generally microservice architecture is respected, but having too many for no reason is a known issue with the pattern. What "too many" is though, I don't think there is a formula that will give you the number
    – Ewan
    Commented Feb 6 at 10:40
  • If the redemption services are always changing, but the account service is finished, then I think I would like not having to redeploy account everywhere when I update a redemption type
    – Ewan
    Commented Feb 6 at 10:42
  • i think it should also be a function of number of clients to account service and kind of redemption logics.
    – best wishes
    Commented Feb 7 at 4:03

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