Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm currently wrapping my head around event sourcing and microservices, and so far, I can image the following approaches. Please correct me if I'm wrong. I'm also looking for other possible approaches.
Approach 1:
Each microservice is connected to a central Event Store. A Microservice A can publish events to the Event Store, other Microservcies subscribe to these events.
Approach 2:
Each microservice has local event store. A microservice A can directly send an event via a message broker to another microservice B.
Approach 3:
Each microservice has local event store. A microservice A can subscribe to an event store of another microservice B.
I suggest the first option. When dealing with any cross cutting concerns you might find it easier to have all your domain events in one place.
We're currently running in production an architecture based on approach 1 with roughly 20 services so far.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
My use case is there will be four microservices A,B,C and D. My input request to Microservice D will be generated based on the outputs from A,B and C.Since A,B,C are independent, Instead of synchronously calling A,B and C thereby blocking the thread and building the request for microservice 'D' after three calls, have planned to call it asynchronously.
Is Akka a good fit for this use case? or it is overkill.
I read that akka is a concurreny tool kit, since my application does not have concurrency concerns, still can i use akka just for asynchrous processing? or is it overkill?
Yes, it is definitely an overkill. If you don't want to block a thread when calling another service all you need is a non-blocking http client. Or even a blocking http client that works on a separate thread pool. Just use anything that returns you Future[ResponseFromService]. akka-http client is one of options. But not raw akka.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm looking for the optimal way to handle the following scenario, preferably some implementation that's already been made for something like this.
There are two Systems (Springboot Webapps) that are supposed to communicate which each other through a Rest-gateway. Transfers shall be handled with Json over HTTP.
1st System is the Project part, 2nd System is the Persons part and they both implement their own persistent sql-database. Both systems depend on each others data and it cannot be expected that both systems are online at all times.
What would be the best way to achieve that both systems data is always up 2 date? Is there any plugin you could recommend to handle the synchronization process which also implements scenarios like one system shutting down while sending or the other way round?
Thanks in advance!
If you can't expect both systems to be online at all times, and you don't want any downtime when one of them is down, I think that the best way to do it is to share a common database. This has some problems of its own and you should think if it's worth, maybe you would be better having two completely independent services which rely on each other and being ready to replicate one of them if it's needed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have to design an application which gets requests from multiple sources like Web service (can be SOAP or REST), online system, Message Queue or some batch job. Application needs to interface with 2 more applications for getting results. I understand that this can be done using microservices. This application needs to be built in Java. I am looking for some framework which can help me with accepting input from multiple sources as mentioned above.
If you want to build a lightweight simple layer (single app) to cater all these requirements, I would recommend using Apache Camel. This single app can listen to rest/soap requests, read from file system, JMS store, database etc. You can even embed it into another application and have all sorts of integration with different data source and excellent and easy to configure routing and transformation engine. Plus the documentation and community is awesome.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a question about messaging systems.
There are two Java applications - A and B. A works constantly and checks the resource. In some cases it need to notifiy B to start. It seems that there is no need to enlarge this messaging later: there will be always two components.
What is the most elegant way to implement it? JMS? Spring Integration somehow?
Another options?
Do I understand correctly that in any case B needs to busily wait?
IMO it is better to use Apache active mq . It is open source and supports JMS 1.1 and J2EE 1.4.
As you are using two applications.You can add the message from A to Active MQ Queue and B would be continuously checking the message queue. So once B receives a message you could perform the operations that you would require.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have an web application that should only differ in one point: if a user is logged in, the data should automatically be saved to a DB.
Non-logged in users should be able to use the full application, but without persistence.
How could one implement this best through the whole application?
Would I have to call some Session.getUser.isLoggedIn() before every action that could potentially trigger a persistence action? That's what I came up so far.
Or are there better ways?
Having to write such behavior in single place would be the best approach.
That can be accomplished in variety of ways and depends on what is your technology stack.
Whats your front end? whats your persistence framework?
Lets say you are calling a Stateless session bean for persistence. you can put an interceptor before that, which would check for logged in user before proceeding.