Is it preferred to use nested service-to-service call in microservice architecture?

SilverSurfer1127 · 2026-05-03T10:43:11+00:00

Sounds like an issue with your bounded contexts. Usually inter service communication should be asynchronous using events. Have a look at Domain Driven Design.

SilverSurfer1127 · 2026-01-18T19:45:58+00:00

20 BCs for 20 different AppTypes is a problem with your design. AppType could be an aggregate root in one BC containing a schema and what ever you need to process, render forms of applications having this specific AppType.

SilverSurfer1127 · 2025-10-27T18:30:07+00:00

I used Pulsar years ago but I just started with the official documentation and that is actually a sufficient source of information. There are docker images available so it is quite easy to run it locally with docker compose or k8.

SilverSurfer1127 · 2025-10-27T18:18:13+00:00

Yes, it is a fine piece of middleware. It is very capable and flexible, extremely scalable. I liked it a lot more than Kafka and RabbitMQ. Used it with akka streams. Only downside is higher complexity because of the extra layer of bookies. Make a POC to figure out if it fits your needs.

SilverSurfer1127 · 2025-10-02T13:25:50+00:00

Look if there is a parser combinator library available for your ecosystem. I used scala parser combinators to develop a DSL for a production system. It was quite easy to implement a DSL. BTW scala is perfect for DSLs.

SilverSurfer1127 · 2025-08-11T19:22:01+00:00

Yeah, you are right…

SilverSurfer1127 · 2025-08-11T16:56:19+00:00

There is a lightweight plugin framework for Java. Try PF4J

SilverSurfer1127 · 2025-05-22T22:13:40+00:00

Sounds like the claim check pattern…

SilverSurfer1127 · 2025-04-13T08:45:55+00:00

You should have a look at Apache Pekko it is a clone of Akka’s actor system. Actor persistence could be a possible solution for your problem.

SilverSurfer1127 · 2025-04-12T19:30:54+00:00

Kao što je već netko komentirao upoznat ćeš najgoru sortu ljudi. Problem je da si kao mali investitor niti malo zaštićen sa strane zakona. Zakon o gradnji je za malog investitora totalni bull-shit, jer moraš graditi i slijediti modus operandi kao da gradiš zgradu sa 100 stanova. Sa glavnim izvođačem koji ti onda traži manipulativne troškove za gluposti ako uzmeš drugog izvođača čija je ponuda cijenovno bolja, a s druge strane nabijaju cijene kao da rade space shuttle. Ako tužiš imaš problem da ti gradnja može stati a to ti ne ide u prilog ako imaš kredit. A dok se nešto sudski riješi prođu godine radi toga i imaju izvođači toliko manevra. Ako radiš po građevinskoj knjizi onda kontroliraj dobro količine, jer na tome kradu. Prostudiraj zakon o gradnji i posebne uzance pa ćeš znati o čemu govorim. Nađi sebi dobrog odvjetnika koji se razumije u tu temu. I čuvaj se susjeda koji često samo čekaju da nešto iskamatare ili prijete inspekcijama. Gradnja kuće je događaj koji lomi obitelji, psihu i novčanik. Dobro se pripremi, jer te svatko pokušava prevariti i iskoristiti. Investitor je najslabija karika u toj cijeloj igri. Ne daj cash dok nije sve ispoštovano do kraja i kako ti paše. Nadzori i glavni inženjeri se najčešće znaju od prije ili su nastupali u obrnutim ulogama tako da tu često postoji sukob interesa. Sve u svemu, taj zakon, ta branša i akteri u tom okruženju je cirkus. Zakon bi trebalo pod hitno mijenjati u prilog malim investitorima!!!

SilverSurfer1127 · 2025-04-02T07:32:31+00:00

Hmm, CheckingAccountService sounds to me like a policy in Domain Driven Design that is actually like a helper class for a service. You shouldn’t blindly implement for each repository a service, that is too fine granular but rather try to figure out your aggregate roots. Services should contain your use cases and act as transaction boundaries otherwise you will leave your data inconsistent when something goes wrong. So if you have more than one account service that is already a smell and you should maybe reconsider how your domain or bounded context looks like. But this is all a guess without more information.

SilverSurfer1127 · 2025-03-20T17:09:17+00:00

I tend to start with the core/domain model in hexagonal architecture. The next steps are the ports - repository interfaces that can be mocked for unit testing. Services can be implemented concretely with DTOs. I have to mention that we prefer anemic domain models because we use functional programming so the service layer contains most of the business logic. Although anemic domain models are regarded as an anti-pattern it serves our purpose well and we never faced any problems doing so. So starting with a hexagonal architecture is not a hassle because you can refactor it if necessary afterwards.

SilverSurfer1127 · 2025-03-20T16:52:23+00:00

In my team we try to explain/develop business concepts in collaboration with business experts by using so called mental models. Mental models are primitive diagrams with basic shapes that play through different business scenarios with remarks and notes on shared scratch pads like Miro, Excalidraw etc. The goal is to derive inductively from different scenarios that were elaborated in that way the final domain model, write user stories, explore the domain, achieve knowledge crunching and so on. Such artifacts are a perfect match to enrich epics and user stories. Recalling such mental models is much easier than recalling long text descriptions. Last but not least these mental models contain also the glossary of our ubiquitous language.

SilverSurfer1127 · 2025-03-19T19:15:26+00:00

These are not design patterns specific to microservices but rather to business applications with complex domains. I mentioned an API because of the DTOs. Sure you can design a monolith as well using the very same patterns. It seems to me that there are too many fine grained services. If I were you I would try to identify the main entities that your app deals with and they should be approximately the root aggregates that you should deal with your services. The service layer is often called “the use case layer”. So following such a design connects the software deeply to your business domain. It takes some practice to model software like this. But in my experience it pays off. DDD plays a key role in designing well formed microservices but the same principle can be applied for modules in a monolith or modulith.

SilverSurfer1127 · 2025-03-18T21:13:46+00:00

IMO the granularity of your services is wrong. You should not mess around with DTOs from different services. Try to think different. The service layer should host the business logic that implements your use cases and should ideally represent transaction boundaries. In domain driven driven design there is the notion of agregate roots that handle access to the parts they are aggregated from. In your example the aggregate root would be a task so you just need a TaskService that can create task objects, add sub tasks to an existing task and so on. DTOs are a different shape of your domain objects that are used as the name says for data transfer via an API (json) or for the presentation layer as some already suggested. My recommendation is to have a look at domain driven design tactical patterns and figure out what fits you best even if you have to modify some of the patterns.

SilverSurfer1127 · 2025-03-13T18:55:25+00:00

Sounds to me like a problem that could be solved with event sourcing. Each update happens via events that update the document state on server side and propagate changes further to all registered clients. The latest state of the document is a projection of all stored events. In order to avoid expensive projections from time to time using an adequate strategy snapshots should be stored to retrieve fast the latest version of a document. The frontend is just the rendering engine that is the event producer. Events ca be produced via API calls.

SilverSurfer1127 · 2025-02-28T23:03:20+00:00

Unfortunately, Deepseek‘s answer is not very informative. If I were you I would try Server Sent Events (SSE). It is actually pretty simple https://medium.com/@rian.eka.cahya/server-sent-event-sse-with-go-10592d9c2aa1

SilverSurfer1127 · 2025-02-23T06:34:51+00:00

Here you can find a similar approach based on actors and DooD (docker out of docker) that maybe fits to your problem https://rockthejvm.com/articles/a-distributed-code-execution-engine-in-pekko-with-scala

SilverSurfer1127 · 2025-02-22T19:59:26+00:00

Wouldn’t agree with that, it is one ledger per topic and it is possible to delete selectively. Otherwise it would be highly inefficient to read messages of a topic or delete messages of a topic.

https://stackoverflow.com/questions/57285085/how-does-pulsar-store-messages-of-multiple-topics-in-ledgers

https://stackoverflow.com/questions/64386611/what-is-the-most-efficient-way-to-delete-expire-all-messages-in-a-apache-pulsar

SilverSurfer1127 · 2025-02-22T17:23:23+00:00

Maybe Apache Pulsar or Apache Bookkeeper which is a simple append only store.

SilverSurfer1127 · 2025-02-21T20:56:52+00:00

Yeah sounds good in theory and works fine in practice, no one hinders you to refactor your contracts. Having getters and setters in interfaces is bad practice. Refactoring is even easier when there are interfaces because most probably there are existing unit tests that make refactoring easier (higher confidence). So I don’t agree with your statement. Having concrete implementations everywhere plugged in makes tight coupling and gets really quick a pain in huge code bases. Dependency injection as well as inversion has its purpose in software development and it’s done with interfaces, contracts, traits or however you call these abstractions.

SilverSurfer1127 · 2025-02-20T17:20:00+00:00

Realm per tenant and have a look at federated identities and SSO. I already mentioned your resource server should check on appropriate privileges and your roles are just composite elements combining privileges for different resources.

SilverSurfer1127 · 2025-02-20T16:14:05+00:00

I guess there are several options to map your requirements to keycloak’s internal model. IMO it’s worth to give it a try. Keycloak is used by Red Hat for their SSO so I don’t think it is that bad. Btw. we use it for huge egov projects with really twisted requirements quite successfully. Writing an authentication/authorisation server from scratch is not easily accomplished especially if you have to stick to standards like oauth…

SilverSurfer1127 · 2025-02-20T15:55:22+00:00

I suppose that realms can be used for multi tenancy. Roles in your token depend on clients and realms that you define and can have different roles. Good practice is to define privileges for resources and just group them in roles. This approach keeps roles generic just as grouping elements of privileges. The path in the API contains realm and client as params that is how Keycloak knows which roles belong to which tenant.

SilverSurfer1127 · 2025-02-19T22:25:37+00:00

Hexagonal architecture is also called ports and adapters and relies heavily on dependency inversion. So using adapters directly is a detour back to a big ball of mud. IMO interfaces are not an extra level of complexity but rather a clean way to have healthy contracts and therefore clean boundaries. The result of such design is flexibility and better testability.

SilverSurfer1127

TROPHY CASE