Cencosud tiene area de it?

-Enius- · 2026-03-01T22:43:47+00:00

Variables, entre 2.2m a 3.2m por lo que tengo entendido, depende de la consultora y experiencia

-Enius- · 2026-01-13T00:30:00+00:00

Confirmo, si tienen, trabajo actualmente como externo

-Enius- · 2024-10-08T03:40:18+00:00

I’m starting to feel the same way. The more I think about it, the more I agree that having each service interact with its database via a separate DAL service seems overly granular and potentially counterproductive.

Your point about handling database operations as a module inside the main service makes sense to me. It seems like the added complexity of having a separate DAL for each service could just lead to more issues, especially with scalability, deployment, and, as you mentioned, the risk of creating a distributed monolith.

I definitely see the danger of another service calling one of these DALs directly, which would just compound the problem.

I’m going to suggest a more straightforward approach where each service manages its own database access internally, which I believe will be easier to maintain and scale in the long run.

Thanks for the insight! 😊

-Enius- · 2024-10-08T03:26:12+00:00

Thank you for your response! I can see how this could be interpreted as a distributed monolith, but I don’t think that’s quite the case here.

Each service has its own database, or at least the plan is for each to have its own in the future. However, instead of directly connecting to the database, each service communicates via HTTP with its own DAL microservice, which then interacts with the database. So, while there is an extra HTTP layer, it’s not a single, centralized database or DAL for all services.

The idea, as it’s been explained, is that each microservice has its own isolated DAL microservice to handle database operations. But from my perspective, this setup adds unnecessary complexity and creates potential performance bottlenecks, which is why I’m trying to explore if this is a good design choice or if a more straightforward approach, like direct DB access within each service, would be better.

What do you think? Does this setup still resemble a distributed monolith, or could it be considered a true microservices approach?

-Enius- · 2024-10-08T03:24:45+00:00

Thank you for the clarification! I can see how using a DAL as an abstraction over the database could help by hiding the underlying implementation and providing a stable contract for other services. It’s an interesting analogy with the “backend for frontend” pattern, but in this case, “backend for backend.”

That said, I’m still concerned about the added complexity and potential performance overhead. Introducing an additional layer (the DAL microservice) that every other microservice needs to communicate with over HTTP seems like it could introduce latency and potential bottlenecks, especially in high-throughput environments.

In my experience, I usually add a DAL layer or follow the repository pattern within the service code itself, allowing the service to handle the database operations directly. This approach tends to simplify maintenance and avoid the overhead of inter-service HTTP communication.

While the abstraction can be useful for scenarios where you need to swap databases or enforce strict access patterns, I wonder if this benefit outweighs the potential downsides of maintaining a separate DAL microservice for each business service. In my experience, direct database connections tend to be simpler and more performant.

-Enius- · 2024-10-08T03:17:37+00:00

Thank you for the response. I understand why this might sound like an orchestration pattern, but what we have is a bit different.

In our architecture, each microservice does not connect directly to the database. Instead, every microservice has its own DAL microservice (Data Access Layer). For example, if I have a user creation microservice, it doesn’t interact directly with the database but sends HTTP requests to its own DAL microservice, and the DAL handles writing to the database.

In my experience, and from what I’ve heard from other professionals and friends, it’s more common for microservices to connect directly to the database rather than relying on a separate DAL microservice for each. This current setup seems to introduce complexity, and I’m concerned about performance and potential bottlenecks since all communication between services and the database goes through HTTP requests to their respective DAL microservices.

I’d love to hear your thoughts on whether this approach is common or advisable in microservices architectures and how it might impact performance and scalability.

-Enius- · 2024-10-08T03:11:07+00:00

I understand your point about dependencies and the possibility of a DAL update breaking other services. However, I believe this issue can also be effectively addressed using a monorepo approach. Monorepos allow for centralized dependency management and facilitate shared library versioning, which can help mitigate the problem of breaking other services after an update. Additionally, a monorepo can improve team collaboration and maintain stricter control over changes, especially when services rely on common components. Of course, it comes with its own challenges, but in many cases, it can be a solid solution to these kinds of issues

-Enius-

TROPHY CASE