New answers tagged

0

This one seems very good micro-service guide: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/, it suggests that micro-services are following a domain-driven design (DDD) and Bounded Context pattern (https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-...


2

If this This means the web developer that is creating the GUI application would need to be in communication with the API devs... who may or may not be in the same time zone etc. is your core issue, your documentation is lacking. Microservices should be self-explanatory enough that barely any dev-to-dev communication is needed. Typically it's just an API ...


2

One option is to have 'Journey' or 'ProcessFlow' microservices where there are back-end micro-services that manage the process flow (or journey) through a state-machine. The state-machine captures the current process state of the end-user and provides an API where the front-end can query the possible next state. This removes the need for the front-end to ...


2

It's not possible to know for sure whether caching your data in Redis would be worthwhile without more information, but: Don't jump to the conclusion that you need to cache the data in Redis. Every dependency you add to a project has a cost. Once you add Redis, you have added one more potential source of problems. When debugging your program, you will now ...


0

If a message is posted by A saying that something has changed, B can consume that message and replicate a local copy of A's info and use that to do whatever B needs to do. If you wanted B to be able to access A's internal data, you would be better of to just give it access to A's internal databases. However you should not do that, the whole point of a ...


3

The idea behind "separate databases" seems to be one that's misunderstood, and I've written about it before here. Having separate databases does not mean separate database server hosts, or even processes. The idea is that the data stored by different applications is isolated. Coming from a background in relational databases (particularly MySQL), this would ...


3

One of the driving ideas behind microservices, is to have independently deployable components: if team A makes a change on microservice a, they should be able to deploy it whenever they want, and team B should be able to deploy their change on service b at their own pace. Sharing a common library is on one side a good thing, because you reuse proven code....


0

I am not sure it solves anything in your particular case, but it can be done. An example: Let's say you are using C#, with Entity Framework Core for database access. In this case all your microservices (the ones made in C# at least) will use Entity Framework Core. In other words, they are all sharing the same library. "But this is not a library I build ...


1

I think you might have a common misunderstanding about what constitutes a microservice. The read and write operations are not services and a microservice is not 1-to-1 with operations. You can have a microservice with both read and write operations. That doesn't make it a monolith. This article gives a nice overview of the concepts of what is and isn't a ...


1

It is really not easy to give a specific answer to this question without knowing the detailed requirements. There is a recommendation: "Keep together what changes together". I would say unless you have requirements that you did not write about, start small! . Put everything in one repository. Have one build job. Deploy together. Until you have a good ...


1

Theoretically, if two microservices read one and the same database then why do you need microservices, but not a monolith? Naturally, it comes the question, what if they read one and the same database, but every service has its own set of tables. Then it seems more acceptable to have separate microservices. To the given question - you mentioned that Redis ...


3

It seems like you are under the impression that each instance of the microservice will also have its own database server that would need to be synchronized with the database servers for other instances. This is not a common implementation. Although you do want database isolation between microservices of different types (an integration database is often seen ...


1

Even if I'm late, I would to put my 2 cents on the argument because I think it's an important point when you want to evaluate e design an event-driven microservices architecture. Each microservice knows exactly which are the events that impact on its state and is able to wait for them. When the microservice is not avaliable, there should be a component that ...


1

Service dependencies (and losing track thereof) are not uncommon with a microservice architecture. It's also expected that services have local data and this data can be keyed with a primary ID from another service. For example, some services are going to have some data attached to a user ID like you observed. You should look at whether or not you have drawn ...


3

The reason why it's generally preferable to separate out writes and reads is because the problems that arise from them are different, and depending on whether your application is read or write heavy you can scale both the services independently. Managing latencies during writes(which are generally higher) and connection count to your databases is much easier,...


0

This is a pretty broad - but good - question, so rather than giving a single answer I'll deal with some of your statements in the hope that it will offer some guidance. One theoretical issue though, while reading up for several microservices architecture resources, I found that, all of them suggests to have Business Logic inside the service so that ...


0

Here's two ideas and techniques that deal with the question "How much data should be returned in a REST API call?" knowing that REST APIs should be designed for an API user (to make sense from the user's perspective) but not over-specialize on one client or use case json:api introduces a powerful concept of related resources and their inclusion. In this ...


3

A lot of it depends on the access patterns of the data, based on which your database is designed and this further influences your design of the microservices. You can think of splitting your entities along verticals (as in Books, Authors and Relationships in separate tables), which in a way automatically leads to 3 different microservices. Of course, in a ...


4

There is a misunderstanding here. Microservices are not designed to work “on a limited pool of data”. Microservices are designed to be losely coupled, independently deployable and scalable. An effective pattern to support these objectives is to let each microservice have its own database. Why ? a shared database might limit scalability; a shared database ...


2

I find this depends on how generic you need the microservice to be. Say you have a microservice which sends emails. You might have a bunch of tables for addresses, body, attachments etc, but the user of the service wont know or care about that. They will just send a single blob of data and expect you to send a bunch of emails. However, you might have ...


0

I think most of your solutions for 2nd and 3rd problem will work. There is not much bad in accessing a service with a HTTP request. Also, you could think about selection replication of necessary data and designing a loose-coupling services.


0

In your flow, I don't see multiple handlers with option for one of them to handle the flow based on condition. It is just a sequence of steps. Generally Chain of Responsibility is used when you have a priority order(not necessarily priority, however there is a sequence) of handlers and each decides whether to handle it there or pass it on. You can definitely ...


0

I'd start with a list of requirements and constraints to drive your decision. Does your app need to run on desktop and mobile? What is the security design? How long does the user stay on the page on average and how data heavy is the application? Who is the intended audience and what might their expectations be on the responsiveness? How complex is the data ...


2

You should probably look over this: AWS lambda best practices. The first bullet is one thing you should definitely consider: Initialize SDK clients and database connections outside of the function handler, and cache static assets locally in the /tmp directory. Subsequent invocations processed by the same instance of your function can reuse these ...


0

I have a different view on the scheduler you have implemented. A scheduler service/module is largely supposed to be very dumb, you provide it a handler, and this gets invoked at a specific time. The scheduler by itself is unaware of the specifics of the handler and the handler should be implemented in its own business module /service. With this view, ...


5

Truly independent deployment means you can upgrade either service in any order and stay in a working state. Obviously, having no dependencies at all is ideal, but somewhat impractical. If you have dependencies between microservices, you can still deploy them independently: In your example, microservice 2 can be upgraded at any time, provided it maintains ...


1

To me, this is important because you can release changes in small batches and manage integration regressions much more easily. With a monolith, you make a change to some feature area, build and deploy the entire thing and hope it goes well. With independent services, it's much easier to roll out small chunks and make sure they continue to play well. Let'...


5

This characteristic is opposed to a monolith and means that you don't need to deploy two services sie-by-side. In a case of a monolith, if you want to deploy a change in one part, you have to deploy the whole monolith. This means that you have essentially three problems: Say you're ready to deploy your change, but the other team working on another part of ...


0

At work I have worked in a similar requirement that you have proposed here. I'd like to answer your questions and give some more hints here. First of all for starters please study this link in order for apprehending the Exchange Types available in Rabbit: https://www.cloudamqp.com/blog/2015-09-03-part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings....


Top 50 recent answers are included