A one-stop shop for migrants and international nomads
Starting as the “rebel of telecommunications”
Founded in Sweden in 2006, Rebtel started in the telecommunications industry helping people make cheaper international calls. Nowadays, the company has pivoted towards offering migrants and international nomads a diversity of services, such as money transfers and mobile top-ups.
Rebtel’s diverse data types
Like any telecom, Rebtel stores and analyzes a large quantity of call data:
“We have a lot of data to monitor our call volumes, call quality, delivery, success rates and the likes,” explained Chandan Singh, Head of Data at Rebtel. “Because we are a paid service, we also have payments and subscription data.”
As Rebtel’s business expands further into new use cases, new types of data, data structures, and data deliveries arrive:
“Now that the business has launched the international money transferring product, we also have data on send volumes,” added Chandan.
Legacy data stack leads to heavy maintenance work and lack of trust
Challenges delivering on business requirements
Rebtel’s business teams needed timely, accurate data to understand how their expansion was performing and confidently make decisions accordingly.
“Stakeholders were requesting different deliverables from the data team,” said Chandan. “But our legacy stack prevented us from addressing as many as we’d like. We had a lot of infrastructure incidents happening on a day-to-day and week-to-week basis.”
Because of all of this firefighting, the data team was unable to dedicate the necessary amount of time to business requests.
Managing the legacy infrastructure, full-time
Rebtel was already using dbt (in the form of open source dbt Core) and Snowflake, alongside GUI ETL tool Matillion. They had migrated to this stack a few years ago from a Microsoft SQL Server stack. Although some issues had improved with the migration, the maintenance load had not:
“A lot of our time wasn't spent actually working on data modeling or data transformation, but on infrastructure,” explained Chandan. “We had our jobs running in Airflow, which was hosted in a Kubernetes cluster within Azure Cloud. The data team was maintaining all of this, which derailed our focus on building data products."
Lack of engineering best practices on Matillion
At the time, Rebtel’s data team operated without engineering best practices—such as documentation, versioning, and CI/CD. This made bug fixing, infrastructure maintenance, and root cause analysis an even greater task.
“In our Matillion setup, we didn’t have a place to create documentation or testing,” said Quentin Coviaux, Data Engineer at Rebtel.
“Without these standards, people could write whatever code they wanted. It was more like every engineer had their own best practices,” said Chandan. ”We couldn’t enforce rules, like using SQL Fluff.”
Because the team hadn’t integrated Matillion with Git, Rebtel also didn’t have code versioning in place:
“You need to upgrade Matillion to have code versioning, but that takes time because you need to spin up new servers, among other things,” said Chandan. “So even though code versioning is essential, we didn’t have it.”
Discrepancies in data and lack of trust
As the number of incidents kept increasing, the trust in Rebtel’s data went the opposite direction. Business stakeholders were no longer certain if the data they were using for decision-making was accurate.
“We were frequently getting questions like ‘Can you tell me if this number is correct?’” shared Chandan. “Although it’s easy to ask the question, for the data person, it would take hours of effort to make sure nothing was broken.”
With the time required to maintain the infrastructure and constantly double-check the data’s accuracy, Rebtel’s data team had little bandwidth to deliver business value.
The last straw: incident leads to loss of historical data
A 2-hour ingestion job failure
Rebtel’s legacy data stack was leading to more and more pain points, which the team flagged and discussed with the business. But it was a 2-hour ingestion job failure that broke the camel’s back:
“The ingestion process was written ages ago and no one in the team knew how it worked. There was no documentation on Matillion we could rely on,” said Chandan.
Challenges rerunning jobs and recouping historical data with Matillion
Around 70 tables were affected in the incident. One of them was the accounting table, critical for the business:
“We spent two weeks fixing just this one table,” shared Chandan “And we realized it was not possible to rerun the transformation in Matillion without spending another few weeks or months to get the data up to date.”
Decision to depreciate Matillion
Given the complexity of retrieving this historical data, Rebtel had to “accept the data loss”:
“That’s when we reevaluated and said ‘Okay, we have to migrate away from Matillion because we cannot afford to be in this situation again,’” said Chandan.
Reflecting on pain points and starting on a holistic data journey
Mission to add value
For the data team, the incident was proof their previous data stack could not support their use cases, and highlighted where they were spending their time. They were working on activities that weren’t adding business value nor improving employee satisfaction or retention:
“As data engineers, we want to create value with data. We don’t really want to build infrastructure or upgrade Airflow versions,” said Chandan.
With this mission in mind, the data team started putting together an architecture diagram to understand the problems to fix in their legacy structure.
Visualizing data stack pain points in a diagram
Rebtel’s data team put all their architecture in one diagram to visualize their pain points. The exercise helped them get the final buy-in from leadership on their digital transformation project. It also assisted them in identifying specific issues to fix on their existing stack:
“We had different redundancy points in our stack, such as doing data transformation on both dbt and Matillion,” explained Quentin.
“Drag and drop” over SQL wasn’t a fit for the team
Data transformations were one of the key problem areas in the legacy data stack. Although Matillion is a “drag and drop” (GUI) tool, the data team was still starting and finishing all transformations on the platform by writing SQL code.
“I’ve worked with Matillion previously and was a big supporter of the tool. But when I came in, I quickly changed my mind,” said Chandan. “We were using Matillion as a scheduler only, not like the ETL tool it is.”
“It’s a good tool if you find it easier to work with a visual tool instead of writing SQL. But we were very comfortable with using SQL for all our data transformations. It made no sense to pay for an expensive ETL tool without using its intended functionality.”
Establishing a SQL-based workflow as the standard, rather than a specialized Matillion skillset, would also facilitate the future onboarding of new data employees.
Depreciating Matillion
As a continuation of their “pain points” diagram exercise, the team started to come up with an architecture that’d best suit their needs:
“Little by little, we removed everything until we had a clean architectural design,” explained Quentin. “Our goal was to remove everything from Matillion—both the transformation and ingestion.”
“Instead of having one do-it-all tool that is a big black box, we separated the extraction and loading from the transformation. That really helped us,” said Quentin.
During this process, Rebtel also migrated from dbt Core to dbt Cloud:
“With these moves, we took away all the infrastructure maintenance overhead we were spending a lot of our time on,” said Chandan.
Reaping the benefits of a transparent, governed data infrastructure
Enforcing engineering best practices with dbt Cloud
Certain engineering best practices—such as documentation and CI/CD—are out-of-box for dbt Cloud and are automatically enforced. With the depreciation of Matillion, Rebtel’s team saw their workflow improve:
“As we’ve been doing the migration from Matillion to dbt Cloud, we have really raised our set of standards for development. dbt made it so much easier to create and maintain documentation,” said Quentin.
“The new stack makes perfect sense for us, which is why we’ve decided to invest more in dbt instead of consolidating in Matillion,” explained Quentin. “Before, we didn’t have any documentation or testing. Now, we’ve set up about 80 tests with dbt Cloud and growing.”
Improved data quality and trust
With the better-governed workflow, data quality has improved and, as a consequence, the business’ trust in data has increased:
“We’ve been focused on making sure people can trust the data we are presenting,” said Quentin. “dbt is really helping in governing our data; it has improved our data quality, which is amazing.”
The data loss incident that kickstarted the stack migration in the first place would also have been easily avoided with the new infrastructure:
“One of the things that works really well on dbt is that you can do a full refresh and catch up on all the transformations in your data pipeline,” said Chandan.
Saving costs and time with a simpler workflow
With the new stack, the amount of time the team devotes to maintenance has dramatically decreased:
“Before, we dedicated three to four weeks per year in maintaining Airflow and the different components of our stack,” said Chandan. “Now we have near zero maintenance work. We don’t have issues with dbt or Stitch.”
By moving from Matillion to dbt and Stitch, the team has saved on licensing costs as well as time. They estimate an 80% reduction in data infrastructure costs.
Bandwidth to focus on non-maintenance activities
With the migration from Matillion to the new stack nearly complete, the team has achieved “data stability.” Instead of focusing on maintenance and infrastructure, they can double down on complex data work:
“Before, we couldn’t kick off any machine learning projects because incidents would get in the way. We had little visibility on our data lineage and code on Matillion, so we never really knew if the data was correct or complete,” explained Chandan. “Now we’re working on an ML fraud prevention use case, which will have a direct impact on our profit margins.”
Moving forward with further automation and advanced data analysis
Automated pipelines and documentation
Although Rebtel has already seen big improvements in data governance, they’re still early in their journey of implementing and enforcing engineering best practices.
“Right now, we have a set of standards that are written in documentation that developers are supposed to follow,” said Chandan. “There are packages that prevent you from pushing code if you don’t have documentation, but we’re not there yet.”
“We’re keen to work on CI/CD pipelines to make the development flow more secure, reliable, and faster,” added Quentin.
Investigate the dbt Semantic Layer and data catalog
The data team has yet to explore dbt Cloud’s features that support a Semantic Layer and data catalog. Together, these two functionalities can help Rebtel improve data accessibility while maintaining data quality:
“We want to work on our data catalog to increase data availability even more for newcomers,” said Quentin. “In the future, we’re also interested in exploring the dbt Semantic Layer and Model Contracts.”
