Differentiate microservice logic by config or a new serviceHow do I achieve the theoretical maximum of 4 FLOPs per cycle?What is the best way to design background jobs in microservices architecture?Text search for microservice architecturesMicroservice vs SOA differsHow do I include end-to-end tests across microservices into multiple continuous delivery pipelines?Microservice calling multiple functions vs custom client specific functionMicroservice relationship/dependency strategyMicroservices data retrieveService B relies on data in Service A: Duplicate data or retrieve on-demand?Mechanisms for response aggregation in event sourcing based microservices
Is it legal to meet with potential future employers in the UK, whilst visiting from the USA
Does French have the English "short i" vowel?
Can I install a back bike rack without attachment to the rear part of the frame?
Is there any relationship between frequency of signal and distance it travels?
Beginner looking to learn/master musical theory and instrumental ability. Where should I begin?
What's difference between "depends on" and "is blocked by" relations between issues in Jira next-gen board?
How to deal with a colleague who is being aggressive?
What was the idiom for something that we take without a doubt?
How do I superimpose two math symbols?
Why did Jon Snow do this immoral act if he is so honorable?
Time complexity of an algorithm: Is it important to state the base of the logarithm?
How does the EU Emissions Trading Scheme account for increased emissions outside the EU?
Best material to absorb as much light as possible
Is superuser the same as root?
Are there any German nonsense poems (Jabberwocky)?
Why would a rational buyer offer to buy with no conditions precedent?
Why did Drogon spare this character?
Count all vowels in string
Mercedes C180 (W204) dash symbol
Find permutation with highest organization number (OEIS A047838)
My players want to grind XP but we're using milestone advancement
Are black holes spherical during merger?
Why did other houses not demand this?
Manager questioning my time estimates for a project
Differentiate microservice logic by config or a new service
How do I achieve the theoretical maximum of 4 FLOPs per cycle?What is the best way to design background jobs in microservices architecture?Text search for microservice architecturesMicroservice vs SOA differsHow do I include end-to-end tests across microservices into multiple continuous delivery pipelines?Microservice calling multiple functions vs custom client specific functionMicroservice relationship/dependency strategyMicroservices data retrieveService B relies on data in Service A: Duplicate data or retrieve on-demand?Mechanisms for response aggregation in event sourcing based microservices
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
We have a Data Processing Pipeline where we receive data from different sources. The entire pipeline is implemented by using Event Driven Architecture and microservices. One of the services has three separate tasks. Two of them are completely common across different sources of data, but the third task scope may change slightly depending on what our data source is. For example, for one source the unique signature may get calculated based on filed1 and filed2, and for another source, it may get calculated based on field2 and field3. How's the best way of implementing this service to be aligned with microservice granularity principles?
Three approaches have come to my mind:
1) Create a single service and use different implementation per source (like a factory design pattern). Depending on the source, one of the implementations will be used at the run-time.
Pros: Less number of services. Less complexity
Cons: Since the service will be shared across all data sources, by adding any new data source this service should be re-deployed which creates an implicit dependency between this service and any service responsible to collect data from a source
2) Break this service into two services, use one for all sources and reimplement the extracted service per data source.
Pros: No dependency between the collector and these two services. By adding a new source a new service needs to be implemented and it does not require to redeploy the services related to other sources.
Cons: More services and since the services are going to be too small we may end up facing nanoservice issue in future.
3) Do not change the granularity of services, but create different instances of the service at run-time. Each with a different config to specify what are the set of fields to be used for each source. In this case, the code is shared, but run-time instances are different depending on which source it belongs to.
Pros: Less number of service, and no operational dependency
Cons: Move complexity of logic to run-time which may make the deployment and operations more challenging
architecture microservices event-driven
asked Mar 13 at 10:36
Ali nAli n
6411130
|
show 7 more comments
We have a Data Processing Pipeline where we receive data from different sources. The entire pipeline is implemented by using Event Driven Architecture and microservices. One of the services has three separate tasks. Two of them are completely common across different sources of data, but the third task scope may change slightly depending on what our data source is. For example, for one source the unique signature may get calculated based on filed1 and filed2, and for another source, it may get calculated based on field2 and field3. How's the best way of implementing this service to be aligned with microservice granularity principles?
Three approaches have come to my mind:
1) Create a single service and use different implementation per source (like a factory design pattern). Depending on the source, one of the implementations will be used at the run-time.
Pros: Less number of services. Less complexity
Cons: Since the service will be shared across all data sources, by adding any new data source this service should be re-deployed which creates an implicit dependency between this service and any service responsible to collect data from a source
2) Break this service into two services, use one for all sources and reimplement the extracted service per data source.
Pros: No dependency between the collector and these two services. By adding a new source a new service needs to be implemented and it does not require to redeploy the services related to other sources.
Cons: More services and since the services are going to be too small we may end up facing nanoservice issue in future.
3) Do not change the granularity of services, but create different instances of the service at run-time. Each with a different config to specify what are the set of fields to be used for each source. In this case, the code is shared, but run-time instances are different depending on which source it belongs to.
Pros: Less number of service, and no operational dependency
Cons: Move complexity of logic to run-time which may make the deployment and operations more challenging
architecture microservices event-driven
asked Mar 13 at 10:36
Ali nAli n
6411130
1
Have you taken into account scalability, criticality of each service, how frequently the new service would have to change, etc? Normally these NFR help defining whether you need to create a service or reuse an existing one (config/feature flags)
– Amin Abu-Taleb
Mar 13 at 10:47
@AminAbu-Taleb Yes. Technically, the frequency of change is the main differentiation point here, as by adding a new source we need to modify this service which is impacted by solution 1.
– Ali n
Mar 13 at 11:09
is there a possibility to build a dynamic rules handler? I met similar problem in building a coupon system. BTW, i think the second one is unreasonable in an enterprise architecture.
– wl.GIG
Mar 29 at 10:00
@wl.GIG What do you mean by a dynamic rule handler?
– Ali n
Mar 29 at 10:16
@Alin like a common handler for all data source with input parameters like [columns: as, bb,..., crypto: xxxxx ]
– wl.GIG
Mar 29 at 10:21
|
show 7 more comments
We have a Data Processing Pipeline where we receive data from different sources. The entire pipeline is implemented by using Event Driven Architecture and microservices. One of the services has three separate tasks. Two of them are completely common across different sources of data, but the third task scope may change slightly depending on what our data source is. For example, for one source the unique signature may get calculated based on filed1 and filed2, and for another source, it may get calculated based on field2 and field3. How's the best way of implementing this service to be aligned with microservice granularity principles?
Three approaches have come to my mind:
1) Create a single service and use different implementation per source (like a factory design pattern). Depending on the source, one of the implementations will be used at the run-time.
Pros: Less number of services. Less complexity
Cons: Since the service will be shared across all data sources, by adding any new data source this service should be re-deployed which creates an implicit dependency between this service and any service responsible to collect data from a source
2) Break this service into two services, use one for all sources and reimplement the extracted service per data source.
Pros: No dependency between the collector and these two services. By adding a new source a new service needs to be implemented and it does not require to redeploy the services related to other sources.
Cons: More services and since the services are going to be too small we may end up facing nanoservice issue in future.
3) Do not change the granularity of services, but create different instances of the service at run-time. Each with a different config to specify what are the set of fields to be used for each source. In this case, the code is shared, but run-time instances are different depending on which source it belongs to.
Pros: Less number of service, and no operational dependency
Cons: Move complexity of logic to run-time which may make the deployment and operations more challenging
architecture microservices event-driven
asked Mar 13 at 10:36
Ali nAli n
6411130
We have a Data Processing Pipeline where we receive data from different sources. The entire pipeline is implemented by using Event Driven Architecture and microservices. One of the services has three separate tasks. Two of them are completely common across different sources of data, but the third task scope may change slightly depending on what our data source is. For example, for one source the unique signature may get calculated based on filed1 and filed2, and for another source, it may get calculated based on field2 and field3. How's the best way of implementing this service to be aligned with microservice granularity principles?
Three approaches have come to my mind:
1) Create a single service and use different implementation per source (like a factory design pattern). Depending on the source, one of the implementations will be used at the run-time.
Pros: Less number of services. Less complexity
Cons: Since the service will be shared across all data sources, by adding any new data source this service should be re-deployed which creates an implicit dependency between this service and any service responsible to collect data from a source
2) Break this service into two services, use one for all sources and reimplement the extracted service per data source.
Pros: No dependency between the collector and these two services. By adding a new source a new service needs to be implemented and it does not require to redeploy the services related to other sources.
Cons: More services and since the services are going to be too small we may end up facing nanoservice issue in future.
3) Do not change the granularity of services, but create different instances of the service at run-time. Each with a different config to specify what are the set of fields to be used for each source. In this case, the code is shared, but run-time instances are different depending on which source it belongs to.
Pros: Less number of service, and no operational dependency
Cons: Move complexity of logic to run-time which may make the deployment and operations more challenging
architecture microservices event-driven
architecture microservices event-driven
asked Mar 13 at 10:36
Ali nAli n
6411130
asked Mar 13 at 10:36
Ali nAli n
6411130
edited Mar 29 at 10:39
Ali n
asked Mar 13 at 10:36
Ali nAli n
6411130
asked Mar 13 at 10:36
Ali nAli n
6411130
asked Mar 13 at 10:36
Ali nAli n
6411130
6411130
1
Have you taken into account scalability, criticality of each service, how frequently the new service would have to change, etc? Normally these NFR help defining whether you need to create a service or reuse an existing one (config/feature flags)
– Amin Abu-Taleb
Mar 13 at 10:47
@AminAbu-Taleb Yes. Technically, the frequency of change is the main differentiation point here, as by adding a new source we need to modify this service which is impacted by solution 1.
– Ali n
Mar 13 at 11:09
is there a possibility to build a dynamic rules handler? I met similar problem in building a coupon system. BTW, i think the second one is unreasonable in an enterprise architecture.
– wl.GIG
Mar 29 at 10:00
@wl.GIG What do you mean by a dynamic rule handler?
– Ali n
Mar 29 at 10:16
@Alin like a common handler for all data source with input parameters like [columns: as, bb,..., crypto: xxxxx ]
– wl.GIG
Mar 29 at 10:21
|
show 7 more comments
1
Have you taken into account scalability, criticality of each service, how frequently the new service would have to change, etc? Normally these NFR help defining whether you need to create a service or reuse an existing one (config/feature flags)
– Amin Abu-Taleb
Mar 13 at 10:47
@AminAbu-Taleb Yes. Technically, the frequency of change is the main differentiation point here, as by adding a new source we need to modify this service which is impacted by solution 1.
– Ali n
Mar 13 at 11:09
is there a possibility to build a dynamic rules handler? I met similar problem in building a coupon system. BTW, i think the second one is unreasonable in an enterprise architecture.
– wl.GIG
Mar 29 at 10:00
@wl.GIG What do you mean by a dynamic rule handler?
– Ali n
Mar 29 at 10:16
@Alin like a common handler for all data source with input parameters like [columns: as, bb,..., crypto: xxxxx ]
– wl.GIG
Mar 29 at 10:21
1
1
Have you taken into account scalability, criticality of each service, how frequently the new service would have to change, etc? Normally these NFR help defining whether you need to create a service or reuse an existing one (config/feature flags)
– Amin Abu-Taleb
Mar 13 at 10:47
Have you taken into account scalability, criticality of each service, how frequently the new service would have to change, etc? Normally these NFR help defining whether you need to create a service or reuse an existing one (config/feature flags)
– Amin Abu-Taleb
Mar 13 at 10:47
@AminAbu-Taleb Yes. Technically, the frequency of change is the main differentiation point here, as by adding a new source we need to modify this service which is impacted by solution 1.
– Ali n
Mar 13 at 11:09
@AminAbu-Taleb Yes. Technically, the frequency of change is the main differentiation point here, as by adding a new source we need to modify this service which is impacted by solution 1.
– Ali n
Mar 13 at 11:09
is there a possibility to build a dynamic rules handler? I met similar problem in building a coupon system. BTW, i think the second one is unreasonable in an enterprise architecture.
– wl.GIG
Mar 29 at 10:00
is there a possibility to build a dynamic rules handler? I met similar problem in building a coupon system. BTW, i think the second one is unreasonable in an enterprise architecture.
– wl.GIG
Mar 29 at 10:00
@wl.GIG What do you mean by a dynamic rule handler?
– Ali n
Mar 29 at 10:16
@wl.GIG What do you mean by a dynamic rule handler?
– Ali n
Mar 29 at 10:16
@Alin like a common handler for all data source with input parameters like [columns: as, bb,..., crypto: xxxxx ]
– wl.GIG
Mar 29 at 10:21
@Alin like a common handler for all data source with input parameters like [columns: as, bb,..., crypto: xxxxx ]
– wl.GIG
Mar 29 at 10:21
|
show 7 more comments
2 Answers
2
active
oldest
votes
I agree with Adrian, it depends on your situation.
I think the most important is system complexity - it plays a critical role in testing, support, and evolution of the system. (KISS)
So I think the best option is 2.
Of course, you should remember other design principles - create libraries for reusing and so on, but in any case, your source code design will be tree not net with unmanaged dependencies.
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
add a comment |
It depends. FYI, I know of Kafka but don't have experience in it.
For option 3: how mature is your ability to manage various instances of the solution with different configuration? How many instances would there be? How would you be able to observe the health, behavior and performance of all the instances?
This option means the development is less complex but the operational side is more complex: you only have one code-base to test but lots of different config permutations to test.
For option 1: would be more complex on the development side, and would still have some complexity for operations. The reason for that would depend on how the solution is set to recognize which implementation to use at runtime. An IOC approach would work but it's still config that needs to be managed.
For both approaches you'd be able to set-up an instance with the right configuration and test it, which is good.
Regarding System Change: microservices should ideally be easily replaceable. Make sure the delineation between services is clean, so that you can ideally replace one part of the solution without breaking the other. It should also be easy to test - both testing the service/module in isolation, and an integrated test with the rest of the solution - and with the relevant configuration - before deploying such a change into production. If you feel one approach is better suited to this that the other then that's the approach I would probably go with.
Update - Option 2
That means having multiple services to handle some requests (but not others) so now you have to manage both the flow between services (at runtime), and also the interdependencies between them (at development, deployment time); harder to test.
Microservices is partly about having services which are independent - option two is not really in-line that ethos - which is ok, just realize it's not strictly a microservice, depending on how particular you are about such things.
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
What are your thoughts regarding option 2?
– Ali n
Apr 10 at 13:15
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55139830%2fdifferentiate-microservice-logic-by-config-or-a-new-service%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I agree with Adrian, it depends on your situation.
I think the most important is system complexity - it plays a critical role in testing, support, and evolution of the system. (KISS)
So I think the best option is 2.
Of course, you should remember other design principles - create libraries for reusing and so on, but in any case, your source code design will be tree not net with unmanaged dependencies.
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
add a comment |
I agree with Adrian, it depends on your situation.
I think the most important is system complexity - it plays a critical role in testing, support, and evolution of the system. (KISS)
So I think the best option is 2.
Of course, you should remember other design principles - create libraries for reusing and so on, but in any case, your source code design will be tree not net with unmanaged dependencies.
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
add a comment |
I agree with Adrian, it depends on your situation.
I think the most important is system complexity - it plays a critical role in testing, support, and evolution of the system. (KISS)
So I think the best option is 2.
Of course, you should remember other design principles - create libraries for reusing and so on, but in any case, your source code design will be tree not net with unmanaged dependencies.
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
I agree with Adrian, it depends on your situation.
I think the most important is system complexity - it plays a critical role in testing, support, and evolution of the system. (KISS)
So I think the best option is 2.
Of course, you should remember other design principles - create libraries for reusing and so on, but in any case, your source code design will be tree not net with unmanaged dependencies.
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
answered Apr 12 at 15:29
A RalkovA Ralkov
624211
624211
add a comment |
add a comment |
It depends. FYI, I know of Kafka but don't have experience in it.
For option 3: how mature is your ability to manage various instances of the solution with different configuration? How many instances would there be? How would you be able to observe the health, behavior and performance of all the instances?
This option means the development is less complex but the operational side is more complex: you only have one code-base to test but lots of different config permutations to test.
For option 1: would be more complex on the development side, and would still have some complexity for operations. The reason for that would depend on how the solution is set to recognize which implementation to use at runtime. An IOC approach would work but it's still config that needs to be managed.
For both approaches you'd be able to set-up an instance with the right configuration and test it, which is good.
Regarding System Change: microservices should ideally be easily replaceable. Make sure the delineation between services is clean, so that you can ideally replace one part of the solution without breaking the other. It should also be easy to test - both testing the service/module in isolation, and an integrated test with the rest of the solution - and with the relevant configuration - before deploying such a change into production. If you feel one approach is better suited to this that the other then that's the approach I would probably go with.
Update - Option 2
That means having multiple services to handle some requests (but not others) so now you have to manage both the flow between services (at runtime), and also the interdependencies between them (at development, deployment time); harder to test.
Microservices is partly about having services which are independent - option two is not really in-line that ethos - which is ok, just realize it's not strictly a microservice, depending on how particular you are about such things.
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
What are your thoughts regarding option 2?
– Ali n
Apr 10 at 13:15
add a comment |
It depends. FYI, I know of Kafka but don't have experience in it.
For option 3: how mature is your ability to manage various instances of the solution with different configuration? How many instances would there be? How would you be able to observe the health, behavior and performance of all the instances?
This option means the development is less complex but the operational side is more complex: you only have one code-base to test but lots of different config permutations to test.
For option 1: would be more complex on the development side, and would still have some complexity for operations. The reason for that would depend on how the solution is set to recognize which implementation to use at runtime. An IOC approach would work but it's still config that needs to be managed.
For both approaches you'd be able to set-up an instance with the right configuration and test it, which is good.
Regarding System Change: microservices should ideally be easily replaceable. Make sure the delineation between services is clean, so that you can ideally replace one part of the solution without breaking the other. It should also be easy to test - both testing the service/module in isolation, and an integrated test with the rest of the solution - and with the relevant configuration - before deploying such a change into production. If you feel one approach is better suited to this that the other then that's the approach I would probably go with.
Update - Option 2
That means having multiple services to handle some requests (but not others) so now you have to manage both the flow between services (at runtime), and also the interdependencies between them (at development, deployment time); harder to test.
Microservices is partly about having services which are independent - option two is not really in-line that ethos - which is ok, just realize it's not strictly a microservice, depending on how particular you are about such things.
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
What are your thoughts regarding option 2?
– Ali n
Apr 10 at 13:15
add a comment |
It depends. FYI, I know of Kafka but don't have experience in it.
For option 3: how mature is your ability to manage various instances of the solution with different configuration? How many instances would there be? How would you be able to observe the health, behavior and performance of all the instances?
This option means the development is less complex but the operational side is more complex: you only have one code-base to test but lots of different config permutations to test.
For option 1: would be more complex on the development side, and would still have some complexity for operations. The reason for that would depend on how the solution is set to recognize which implementation to use at runtime. An IOC approach would work but it's still config that needs to be managed.
For both approaches you'd be able to set-up an instance with the right configuration and test it, which is good.
Regarding System Change: microservices should ideally be easily replaceable. Make sure the delineation between services is clean, so that you can ideally replace one part of the solution without breaking the other. It should also be easy to test - both testing the service/module in isolation, and an integrated test with the rest of the solution - and with the relevant configuration - before deploying such a change into production. If you feel one approach is better suited to this that the other then that's the approach I would probably go with.
Update - Option 2
That means having multiple services to handle some requests (but not others) so now you have to manage both the flow between services (at runtime), and also the interdependencies between them (at development, deployment time); harder to test.
Microservices is partly about having services which are independent - option two is not really in-line that ethos - which is ok, just realize it's not strictly a microservice, depending on how particular you are about such things.
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
It depends. FYI, I know of Kafka but don't have experience in it.
For option 3: how mature is your ability to manage various instances of the solution with different configuration? How many instances would there be? How would you be able to observe the health, behavior and performance of all the instances?
This option means the development is less complex but the operational side is more complex: you only have one code-base to test but lots of different config permutations to test.
For option 1: would be more complex on the development side, and would still have some complexity for operations. The reason for that would depend on how the solution is set to recognize which implementation to use at runtime. An IOC approach would work but it's still config that needs to be managed.
For both approaches you'd be able to set-up an instance with the right configuration and test it, which is good.
Regarding System Change: microservices should ideally be easily replaceable. Make sure the delineation between services is clean, so that you can ideally replace one part of the solution without breaking the other. It should also be easy to test - both testing the service/module in isolation, and an integrated test with the rest of the solution - and with the relevant configuration - before deploying such a change into production. If you feel one approach is better suited to this that the other then that's the approach I would probably go with.
Update - Option 2
That means having multiple services to handle some requests (but not others) so now you have to manage both the flow between services (at runtime), and also the interdependencies between them (at development, deployment time); harder to test.
Microservices is partly about having services which are independent - option two is not really in-line that ethos - which is ok, just realize it's not strictly a microservice, depending on how particular you are about such things.
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
edited Apr 29 at 3:54
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
answered Apr 1 at 4:07
Adrian KAdrian K
6,57432339
6,57432339
What are your thoughts regarding option 2?
– Ali n
Apr 10 at 13:15
add a comment |
What are your thoughts regarding option 2?
– Ali n
Apr 10 at 13:15
What are your thoughts regarding option 2?
– Ali n
Apr 10 at 13:15
What are your thoughts regarding option 2?
– Ali n
Apr 10 at 13:15
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55139830%2fdifferentiate-microservice-logic-by-config-or-a-new-service%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Have you taken into account scalability, criticality of each service, how frequently the new service would have to change, etc? Normally these NFR help defining whether you need to create a service or reuse an existing one (config/feature flags)
– Amin Abu-Taleb
Mar 13 at 10:47
@AminAbu-Taleb Yes. Technically, the frequency of change is the main differentiation point here, as by adding a new source we need to modify this service which is impacted by solution 1.
– Ali n
Mar 13 at 11:09
is there a possibility to build a dynamic rules handler? I met similar problem in building a coupon system. BTW, i think the second one is unreasonable in an enterprise architecture.
– wl.GIG
Mar 29 at 10:00
@wl.GIG What do you mean by a dynamic rule handler?
– Ali n
Mar 29 at 10:16
@Alin like a common handler for all data source with input parameters like [columns: as, bb,..., crypto: xxxxx ]
– wl.GIG
Mar 29 at 10:21