Leobit
Internal Enterprise Trading and Hedging System
Comprehensive architecture and technical assessment for a global agribusiness enterprise company that helped them find out and address architectural flaws before going to production
ABOUT the project
- Client:
- Global Agribusiness Company
- Location:
-
Switzerland
|Geneva
- Company Size:
- 10,000+ Employees
- Industry:
-
Agriculture
- Solution:
- Architecture Assessment
Services:
Technologies:
Leobit conducted a comprehensive architectural and technical assessment of an internal multilayered software system used by a global agribusiness enterprise. The software serves for trading and hedging purposes and is supposed to be used by company employees. The solution had been under active development for approximately two years and reached the R2 release stage.
According to the customer’s internal protocol, any project approaching production must undergo an independent architecture and code review by a third-party vendor to validate overall quality, risks, and readiness. Leobit was engaged to perform this independent assessment.
One of the challenges of this project was a strong focus on security from the client: architectural review had to be commenced in full isolation from the development team, using a client-provided environment, without access to any monitoring data (not even a test environment), and without being able to run the project locally.
I was truly impressed by the level of security involved and the high quality of the code I was reviewing. The team was definitely highly experienced. However, once I’ve comprehended the wide-scale patterns and the solution architecture overall, sadly, some serious architectural flaws started to arise. I’m happy the client still has a couple of months before the go-live to address those, but the issues would have been far less costly if a review had been done in the early stages of the project, before it grew this big.
Customer
Our customer is the global agribusiness arm of the largest food and agriculture company, operating across more than 30 countries, with around 11,000 employees and a fully integrated global supply chain. It is one of the world’s major traders of grains, oilseeds, sugar, and other agricultural commodities, with strong logistics assets in Brazil, Argentina, the U.S., Europe, and Asia.
Business Challenge
The customer had rewritten their legacy monolithic web-based application using .NET and Angular, adopting a microservice architecture. They were seeking a comprehensive assessment of the solution implementation quality post-R2 release.
Why Leobit
The customer chose Leobit for our experience in .NET technologies, micro-service architectures, and working knowledge of applying ISO/IEC 25010 for quality assessments. Equally important was Leobit’s ability to go beyond surface-level analysis. The customer needed not only a list of issues but also a clear explanation of why certain architectural decisions posed risks, how those risks could manifest in real business scenarios, and what practical steps could be taken to address them.
Project
in detail
Leobit conducted a comprehensive audit that helped the customer identify architectural, data consistency, and scalability risks early, before the system entered production.
Our senior solution architect performed an in-depth manual review. This included reviewing architectural decisions, service boundaries, API design, domain modeling, security practices, and documentation. Manual analysis was critical for identifying systemic architectural issues, related to eventual consistency guarantees, domain-driven-design concepts misuse, risks of improper architectural choices and service API design flaws.
The assessment revealed that the project was built on a microservice template that contained structural flaws. As a result, those flaws were replicated across multiple microservices, making them costly to address at the current stage of development. Due to the absence of template versioning and an update plan, fixing these issues will require coordinated refactoring efforts in many places rather than focused changes.
An often-seen architectural mistake is assuming that a monolith can just be broken down into a bunch of microservices as long as API backward compatibility is maintained, focusing solely on structural compatibility and forgetting about behavioral compatibility. That is, eventual consistency guarantees, which are the heart of any microservices architecture, are rarely sufficient for client-side apps built with strict transactional guarantees in mind. Since the decision justification did not describe the anticipated impact, external dependencies will likely need subsequent updates to align their expectations.
During the review, the Leobit expert discovered several flaws in the design of the data replication mechanism, which is widely used for microservices synchronization. While almost undetectable through manual testing, those would have caused serious data consistency and performance issues under production load, leading to inaccuracies in reports and other use cases.
Due to limited back-end domain modeling, the front-end layer assumed responsibility for enforcing business rules and workflow sequencing. While this might work in simple scenarios, it does not scale reliably for complex workflows. The result was an overly “smart” front end with intrinsic concurrency handling on the back end, which still could not guarantee data integrity. At the same time, back-end services lacked the authority and information to reliably enforce consistency of workflows. Leobit recommended re-centering business logic within back-end services and gradually re-designing APIs around real domain operations rather than pure CRUD APIs.
From a security perspective, the system expectedly demonstrated a high level of maturity. That said, Leobit identified several process-level improvements that could further reduce the risk of security vulnerabilities emerging over time, particularly as the system scales and more teams contribute to its development.
Architecture documentation and domain alignment
The review revealed that though the technical documentation was generally well structured, it still lacked critical context. While selected architectural decisions were described, they were not clearly justified in relation to business requirements or domain workflows. The existing documentation doesn’t cover functional requirements, expected system load, usage patterns, or scalability needs.
As a result, several architectural choices appeared to be driven by a generic template rather than by the specific needs of a trading and hedging domain. This made it difficult to assess whether the system was overengineered in some areas and underprepared in others. This particularly referred to consistency, workflow orchestration, and data ownership.
CRUD-centric API design and business logic ownership
Our assessment revealed the widespread use of CRUD-style APIs across back-end services. While CRUD APIs are not inherently problematic, in this system, they did not encapsulate business logic and instead acted primarily as a thin data-access layer.
This approach shifted responsibility for business rules and workflow enforcement to the front end. As a result, back-end services did not enforce workflow consistency, especially in scenarios involving multiple concurrent users. The front end, in turn, became increasingly complex as it attempted to coordinate workflows that, ideally, should have been enforced server-side.
In a large enterprise system, this design introduces a high risk of bugs due to shared responsibility for workflow state consistency. Leobit concluded that APIs should (in the long run) be redesigned around business operations and domain-specific actions rather than generic create, update, and delete events.
Event handling and data consistency risks
Upon an architecture audit, our solution architect discovered that the system heavily relied on asynchronous communication between services. The “Domain events” were made heavily CRUD-focused — just like the APIs, thus violating the Domain Driven Design architecture principles by ignoring the “Aggregates” concept.
Such a design, especially in combination with the choice of Azure Service Bus topics for messaging, would lead to data inconsistencies across services due to the unordered delivery nature of the Service Bus. For a trading system, where correctness and traceability are essential, these risks were considered significant and required architectural reconsideration.
Leobit recommended identifying the entity groups that require strict consistency and redesigning data replication events to align with those boundaries. For the remaining isolated entities, it would be enough to enforce ordered delivery of CRUD updates via ServiceBus sessions, or by switching to an Event Hub.
Technology Solutions
- Performed manual code and architecture review, because static code analysis tools like NDepend or SonnarQube were restricted due to the specifics of the provided virtual development environment.
- Used Trivy scanner for security vulnerabilities discovery.
Value Delivered
- Prepared a comprehensive report on meeting the best practices regarding solution architecture, patterns applied, code quality, security, database organization, technical documentation, and other aspects of the project.
- Provided clear, actionable, and prioritized recommendations aligned with the project strategy of getting into production and ensuring smooth operations as soon as possible.
- Delivered actionable recommendations aligned with ISO/IEC 25010 to help the customer improve reliability, maintainability, and functional suitability of their internal solution.
- Provided a clear roadmap for incremental architectural improvements that don’t require a full system rewrite
