New answers tagged

0

A general idea to cut your issues down with the aim of Microservices paradigm would be a strategic pattern of DDD which called context mapping. In the context mapping you define the type of the relations between your bounded context and you shape your domain models which may seem are duplicated in names, though these are different in usage. For the example ...


0

As it seems the County entity can't be a rich model of your business. Using DDD alongside CQRS would solve your basic question of responsiblity sergration. In you Core service (country is an entity of this domain) write your command which can mutate the state of this bounded context. Other services can query the needed data from this service effortlessly. ...


1

Data is not a service. Access to data may be a service. Processing data definitely is. You should ask yourself: what does my system do with that data? What is the service interface that my domain components require to access in order to use the country data? And then: Do all my components agree on the syntax of that interface? Do all my components agree on ...


0

3 is the correct option with microservices. The idea is for each microservice to protect and own its data. This keeps it consistent and allows you to restrict the impact of code changes as well as all the other microservice goodness. You are avoid the single point of failure with various standard High Availability techniques. This design should work well ...


1

tbh I'm still not 100% sure what you are asking. But I'll give you a general answer on the topic of exposing APIs for use when you have a "massive domain" by which I take to mean, you have lots of microservices for various parts of your business. "API Gateway" is a generic term that has no "official" meaning. You don't need an "API Gateway" You can add ...


4

1 or 3 depending on the data and your needs. A shared database is a no-no since it then means your services are not independently deployable and scalable. You need one service that owns the data and is its source of truth. It can then make sense to also replicate the data to cut down on latency if that is more important than the data being up to date.


0

After wider research, thinking, and taking the other answer and the comments into consideration, I have arrived at the following conclusion: For issue 1, using a shared library is perfectly valid and the ideal solution here, as it avoids code duplication without actually coupling the containers, as long as proper encapsulation and semantic versioning ...


0

Option 1 is good, don't pass the context around, it will tightly bind your UI to the logic. Think in the following way :- Your UI components should not know of what is happening when the User enters the Data UserAccessInformation extractAccessInformation and then pass all this to a class where Pre Processing will happen, on the data. UserDataProcessing ...


1

The idea of a message bus is to run things asynchronously. Message exchange is not supposed to take place while a client is waiting for your response. It should happen in the background, so for example if your ProductService needs some data about users, it should listen to events from UserService about user changes, and apply them to its own local copy of ...


0

how do we tell the user whether their order was successful, as the client is expecting a synchronous response from the order service? In case of a web application, you could e.g. have a text "Payment: pending" being displayed when the order service responses. Then, you would use a JavaScript poll function periodically asking the order service whether ...


1

All communication to web servers is already asynchronous... Because they are using a computer network. The client makes a request, it goes to the network, and eventually, a response arrives. You can have asynchronous code be multithreaded, and you can have it single threaded. You could convert something synchronous into something asynchronous by using ...


1

I think you have a misconception about what asynchronous means. Almost all communication to web servers from browsers is already done asynchronously, because JavaScript only has one thread. Yes, the request and response are correlated together, but any number of things can happen between the request and the response, and while the response is outstanding, it ...


0

Typically you'd want to use something like WebSockets to send your request from the OrderService to the PaymentService. The PaymentService would immediately send back a reply saying it received the request for payment. It would then (for example) forward the request to the bank, and probably send the OrderService another message saying the payment request ...


0

We do some event processing at very low scale using AWS and a "push" model. Roughly, the design looks like this: SNS is used by a publisher to `fan-out` SQS is used by a subscriber to `fan-in` Triggers are used to fire the subscriber function when there is work available in the queue. When we deploy a new lamdba, the same template that creates the ...


1

A lot depends on the details, but in general I would try to avoid having synchronous dependencies if I have full control over the design. For example if you already know that the service will need to chain-call to downstream services, why not try to design the system in a way that whatever information is needed is at the node where the request comes in. In ...


0

Your Architecture looks good. You have seperated the concerns and have a good grasp of the domain you are working in. Q1 Order Management and Shopping Cart are the Customer facing parts of your application or the business-relevant aggregation of your services 1-4. Q2 Communication via messaging is a reasonable choice - but not the only one you have. You ...


2

When building microservices, we can choose to use a dedicated database for each service or share one database with multiple services. However, the repository code should always belong to only one service. Using microservice, we want to make the development and deployment of each service to be independent of each other. If the repository code is used by two ...


0

Versioning your sdks. You need a versioning strategy in place to avoid disruption/downtime. Here's a good lead on how ING managed their versioning, there's a youtube presentation of this talk as well. https://www.slideshare.net/PatriceKrakow/api-versioning-for-zero-downtime-devoxx-belgium-2017


2

It's hard to get around the fact that if two programs talk to each other they have to agree on the message format. Not every change to and API requires a client change though. I normally separate out publishing the MicroService from publishing its client library. That way if you fix a bug and have interface changes in a version, you can update the server ...


0

You should be able to go serverless by pointing directly from a Python package dependency file to the private GitHub repos containing the libraries. Pipenv and Poet both support this, I believe.


0

Yes. Streaming architecture (where the interaction is done through a streaming platform (Kafka, AWS Kinesis etc)), RPC so on and so forth. You'll need orchestration software, dedicated databases for each microservice etc. In all honesty, if you don't see the benefits and have no clue as of yet how to put it all in place and no performance benchmarks ...


0

Don't replicate data. Report data. The main principle of micro-services is that each service is the single authority. Nothing else gets to act like it knows the current value as well. The current value lives in only one place. Your 3rd service is an aggregator. It might be a handy abstraction but is not required. Aggregation can happen client side. ...


1

Since you are using micro-services I am guessing that you are using token based authentication/authorization which means that you have a signed token in which you can securely pass data from a client to a service and from service to service to authorize requests. If not I would suggest to do so because this will enable you to: Capture/Recognize the tenant ...


0

If the Go application is itself a server, then I see no reason why you need to build an intermediate server to handle the DB interface. At that point you're probably over-designing things. Use the standard client libraries, that is what they are for. If the Go application is the client (such as a command line tool) that is used 'out in the wild' on ...


2

In Microservice architecture, often the goal of Microservices is to find "seams" and break up the services along those seams. If you have multiple services "coming together" in a single database, then you're, in essence, breaching the seam. It appears you're splitting your seam in the wrong way. It's my understanding that any given service can definitely ...


Top 50 recent answers are included