Tag Info

New answers tagged

1

The best way is to make the REST api but copy data over in a scheduled job. Sharing databases should always be avoided between solutions. Remember we don't share toothbrushes and connectionstrings. By exposing the inner workings of the db you lock the cadance of both apps to each other and neither of them can have their inner workings changed to a more ...


-1

You could use Federated tables. http://www.fromdual.com/federated-storage-engine


0

One way of doing this would be to creation an Application_3_API_service which would expose an API to both Application_1 and Application_2. All services that currently do read/write operations in Application_1 and Application_2 would now hit various endpoints exposed on Application_3_API_service. The only application with a database connection would be ...


4

Since you tagged the question with SOA, I suspect that you're thinking the right answer might be using a service interface. Such a service interface should not expose the data, but the functionality you want to provide as a contract to be exposed by one application and consumed by the other application. As the question is being asked in the abstract, ...


0

State management (potentially a database) can be deployed in the Microservice's container and exposed via an API. The a Microservice's database is not visible to other systems outside the container - only the API. Alternatively you could have another service (e.g. a cache) manage state via an API. Having all the Microservice's dependencies (other than API ...


2

The usual approach is to isolate those microservices as much as possible - treat them as single units. Then transactions can be developed in context of the service as a whole (ie not part of usual DB transactions, though you can still have DB transactions internal to the service). Think how transactions occur and what kind make sense for your services then, ...


1

I think if consistency is a strong requirement in your application you should ask yourself if microservices is the better approach. Like Martin Fowler says: Microservices introduce eventual consistency issues because of their laudable insistence on decentralized data management. With a monolith, you can update a bunch of things together in a single ...


1

I think the standard wisdom is to never have transactions cross microservice boundaries. If any given set of data really needs to be atomically consistent with another, those two things belong together. This is one of the reasons it is very hard to split a system into services until you have fully designed it. Which in the modern world probably means ...


2

In the example you use there is nothing that can be parallelized. Each step requires data from the previous. Hope you are using better example for your design drafts. The direction in which you are heading requires quite elaborate orchestration (as you have realized yourself) and this is non-trivial problem. One possible technical option is to use ...



Top 50 recent answers are included