Oracle Database migration to microservices architecture on AWS

e-Core • May 2, 2023

About Concil


Concil was founded in 1993, with the objective of helping companies of all sizes and segments to have access to effective financial management for their business, providing results that are more efficient and reliable. Its purpose is to transform financial management into something simple, unified, and smart. To do this, it uses technology, unified information, and strategic partnerships to provide secure decisions, time savings, and financial results.



Currently, the company has more than 6,000 customers, through its General Ledger Reconciliation (Concil Contábil) and Card Reconciliation (Concil Card) solutions, making financial management easier and faster, providing more efficient and reliable results.


The Challenge

With a wide variety of customers, Concil processes more than 50 million transactions monthly, generating more than 300 million lines of data to be analyzed, applying complex business rules to deliver financial data reconciliation results.


Concil wanted to increase the number of customers. However, a major challenge was scaling up data processing capacity at the speed required for the data reconciliation process, while keeping prices under control.


The solution originally used was based on data processing directly in an Oracle database, hosted in the Oracle Cloud, and the complex transformations performed overloaded the database, slowing down analytics and hindering the addition of new customers.

The Solution


To overcome its challenges, Concil counted on Solvimm’s (an e-Core company) support to develop a scalable and event-driven solution on AWS, where a premise was the processing of files using independent resources, based on best practices of microservices architecture. In other words, each file would be processed in most of the data stream using computing resources only while it is being processed, minimizing the amount of idle resources, reflecting directly on cost optimization.

The strategy to improve data management was to use the Lakehouse concepts, enabling unified governance for easy data movement, as well as Apache Hudi that efficiently manages the business requirements. This improved data quality, in addition to promoting ACID properties for Amazon S3 data.


Throughout the process, data processing was performed in Apache Spark on batch EMR Clusters and the data queried by analytical processes via Amazon Redshift. 

The Challenge

Concil can now process thousands of files in minutes, enabling it to expand its business without the infrastructure being a bottleneck for processing. With the implemented solution, it was possible to process 10 times more files per minute, which was one of the main bottlenecks of the previous model, increasing by more than 20 times the capacity to receive new customers, while facilitating maintenance by reducing the complexity of the database schemas.


Moreover, another key item was the easy maintenance of the solution, reducing the number of database schemas by 600 times.


* Originally published by AWS

LET'S CONNECT

Ready to unlock your team's potential?


e-Core

We combine global expertise with emerging technologies to help companies like yours create innovative digital products, modernize technology platforms, and improve efficiency in digital operations.


You may also be interested in:

Por Adriele Radmann 3 de agosto de 2026
Discover why customer support is your strongest shield against churn. Learn how to connect support, product dev, and AI to protect recurring revenue.
23 de julho de 2026
See how Banco Inter migrated to Jira Cloud, cut $200K in annual costs, and boosted team efficiency with e-Core as its implementation partner.
Por Flávia Batista 10 de julho de 2026
There is a belief that runs deep inside IT operations teams: a noisy environment is a healthy one. If alerts are firing constantly, if tickets are piling up, if the on-call rotation is getting hit at 2am, that means monitoring is working. The tools are catching things. I understand where this comes from. In the early days of observability, silence was genuinely suspicious. A quiet dashboard often meant a gap in coverage, a misconfigured rule, something important slipping through undetected. So teams learned to treat volume as proof, and that instinct stayed long after the environment around it changed. But noise is not proof that monitoring is working. In most cases, it is proof that something upstream was never fixed. Automation at the wrong end When alert volume becomes unsustainable, the response is almost always the same. Leadership looks at the backlog (a thousand tickets a day, engineers buried, SLAs slipping) and reaches for automation at the remediation end of the pipeline: AI agents plugged into monitoring tools, scripts that fire when incident X arrives, routing logic that moves tickets faster. These are reasonable responses to an unreasonable situation, but they treat cost rather than cause. Most of those alerts should never have been generated. Processing them faster does not change why they exist.