[MUSIC PLAYING]
BRUNO AZIZA: Hi, everyone.
I'm Bruno Aziza.
And welcome to another episode of "Data Journeys."
This is the place we come to learn
from data leaders who have experienced amazing growth,
amazing success.
And today, I have the pleasure of talking
to Ryan, who is VP of engineering at Tokopedia.
Tokopedia is based in Asia.
It's a fast-moving organization, millions of customers,
millions of products.
And Ryan is going to tell us everything about their scale.
Ryan, thank you so much for spending the time
to talk to us today.
RYAN DE MELO: Thanks, Bruno.
Thanks for the quick introduction.
Glad to be on the show.
BRUNO AZIZA: All right, well, let's dive right into it.
Not many people might know who Tokopedia is, so
what do you guys do?
RYAN DE MELO: That's a good question.
Based out of Indonesia, Tokopedia initially
started off about a decade ago in the marketplace space,
and eventually, we have grown crazily.
We've got about 500 million products.
We've got a whole bunch of businesses
across payments, fintech, logistics, digital products.
We've got 40 digital products.
We've reached 99% districts in Indonesia
and got about 11 million merchants.
So that's where we've come over the last 10 years.
BRUNO AZIZA: And so you've built this super ecosystem.
It's marketplace for business lines, marketplace,
digital goods, fintech and payment, logistics, retail.
So that means you have a lot of data
and you're introducing a lot of products every week.
And so tell us a little bit about the use cases.
How are you using this data to run a better business
and create better experiences for your customers?
RYAN DE MELO: So while Tokopedia is
all about democratizing commerce for end customers,
we also, internally, want to make sure that--
we initially started off with the physical goods business.
But as we scale up and launch more businesses, each business
that is spun off, what can they benefit out of the ecosystem?
And now, one thing is you have the cash flow,
you have the customer base.
But also, beyond that, how you can quickly spin off what
other assets are then?
Obviously, the next big one is data.
So that's where we want to see what we can leverage,
what data sets we can leverage that will not only
help new businesses come on board
but will also benefit our customers,
that if there are any gaps that they had
in their overall journey or in their life,
how it can be filled.
That's something that we've really invested a bit.
BRUNO AZIZA: And so you use-- from an infrastructure
standpoint you use BigQuery, Bigtable, Dataflow, Pub/Sub.
And you've created kind of these environments
where you have a customer data platform, a product data
platform, a merchant data platform
to create these experiences.
Tell us how do they work together,
and what's the infrastructure under that?
RYAN DE MELO: That's a good question.
Sometimes we use-- we're early adopters
of literally every product that the Google data team launches.
And in fact, when we were building out
of your data catalog we were one of the first customers.
Forget about scale, but we were one of the first customers.
Because I think the notion behind our evolution is we
are very lean.
Till 2020, we had 15 data engineers
considering the kind of scale and the kind of data volumes
that we have.
What we did is we didn't ma--
we did transitions.
We started off like a typical startup.
You want to keep costs low.
You want to start off with open source tooling.
We used [INAUDIBLE] and we deployed through it.
But then we realized that it's reached a point wherein
our centers are being affected and our business growth
is being affected.
And that's when we transitioned onto the data platform
we started, the first one was, obviously.
But some sync the data and get ready to create
your data link and [INAUDIBLE],, everything else from there on.
So you're right, we use about at least seven of them.
Last, we used seven of those products out there.
BRUNO AZIZA: So that's amazing.
And you've done this migration to your seller analytics
engine.
Tell us a little bit about that.
What's the use case like?
RYAN DE MELO: Seller analytics was an interesting area,
considering the number of businesses and offerings
that we had to a seller, whether he's looking at marketing,
he's looking at payments, fintech,
using some of our fintech products
to further toward his business.
If he has one dollar, where is he
going to leverage that dollar?
And how is he going to track how well it's doing?
So from that standpoint we realized
that our old data warehouse really could not scale.
Now, when we look at sellers, sellers
exist in different personas, in different shapes
and different sizes.
So it really creates a whole bunch of these options
that we need to provide to keep a considerable volume
of our sellers happy.
That's how we realized that previously we
wanted to build a specific widget, a specific performance
widget-- now what is a widget?
A widget is basically just--
it is just some statistics that will be available to a seller,
depending on the different products he uses.
Now, he could have widgets in terms of showing
him sales, his sales by region.
He could have a widget in terms of showing him
his overall delivery SLAs, in terms
of how this marketing has been doing,
what's his conversion rate.
So we realized that, looking at all
these different combinations, we needed a dynamic platform.
We needed something that was ready, every business team--
ready to businesses that we have, to go and spin off
widgets very quickly.
That's when we created the base infrastructure on top
of the Google data platform.
What we saw is that, previously, when
it took two months to roll out a widget,
now it was a mere two weeks.
BRUNO AZIZA: That's pretty amazing.
To go from two months to two weeks,
that's a lot of productivity.
What about the performance, or the gain,
from an elasticity standpoint?
RYAN DE MELO: Again, the stock that we
picked was Pub/Sub, BigQuery, Dataflow,
Bigtable, and Elasticsearch.
So we saw a tremendous drop.
We saw about a 25% cost efficiency,
due to the elastic nature of infrastructure
provided by the Google data platform.
In terms of our seller widgets, we drastically saw a reduction
from around 11 milliseconds to 7 milliseconds,
which was really interesting.
So you had the cost benefit and you also
had the reduced latency.
BRUNO AZIZA: So that's a pretty amazing journey.
I noted on your profile that previously you also built
a system that could ship 12 million orders a day,
serving 3 billion targeted ads a day.
So you know a lot about scale.
What would you say are the best practices, maybe
the set of best practices you'd tell anyone
to look at if they want to have a similar success to yours?
RYAN DE MELO: That's a good question, Bruno.
I think, getting back to where we started,
it's very clear to have a few key items.
One is data quality and understanding
your single source of truth.
Now, as you have data that resides in your warehouse,
has been replicated across different use cases,
that you might have more front-facing,
some might be more about business analytics
and whoever are the intended customers.
It's really understanding what's your single source of truth.
A very, very clear metrics definition now,
when we have very different businesses,
when we want to look at them from a bird's-eye view,
we need to make sure that these metrics can actually be
aggregated and rolled up.
So that's very critical.
You can have your granular metrics that
exist in your specific business unit,
but you need to make sure that, hey, these
are available when maybe the c-suite want to use it
or we want to use it for any other internal purposes,
within across different businesses.
So I think that's also true with the data quality associated
with data, very clear labeling in terms
of the kind of different infrastructure assets
that you have.
You never know-- you know, today, you start off,
you might have few assets that, later on it will scale up.
It will scale up.
And then you'll be having thousands and thousands
of different services final, so having
the little process-oriented bits like clear labeling, clear cost
monitoring.
Because costs with data can go up exponentially,
so really understanding what's driving your cost
and what are the underlying business
metrics achieved by that spend.
So that's very critical.
Because your CFO is going to come and say, hey,
what happened?
So then that's where you need to have those all there.
And really understanding what are the permissions associated
with data, you do not want any leakages to happen.
And I think that's where the Google data
platform has an amazing IDM and audit control.
So you can literally get these off in a few clicks
without too much of DevOps investments.
BRUNO AZIZA: That's great.
That's a lot of best practices-- data quality,
metric definition, labeling, costs, and then, of course,
security.
What about the flip of that?
What are some of the bad practices
that you've witnessed or maybe something you
would tell yourself at the beginning of this journey that
might make sense at the beginning
but now, in retrospect, it could have been something to avoid?
RYAN DE MELO: Some of them, we learn from our mistakes.
So like, for example, this query that was running and scanning
petabytes of data, we realized what
were the kind of safety mechanisms
that BigQuery had to offer.
That's why we kind of looked at the whole fixed-slot model.
So it not only solved these problems,
but it also helped us in our overall budgeting,
where we could start assigning different slots to businesses.
So depending on your shape, size, and amount,
generally, just think, we can assign
you a set number of slots.
And you can both make [? money ?] with them,
run all your jobs.
Today, you realize that you've reached the next leg
of the journey, invest more.
So it was not there.
Another interesting bit is when we look at Bigtable.
Bigtable, you can also offer scalers.
So when you have your real big sale events,
you can scale up and scale down.
It's very, very seamless.
So that's another key aspect to keep in mind.
BRUNO AZIZA: What's your point on auto scaling of slots on top
of fixed slots?
I'm trying to understand.
RYAN DE MELO: Yeah.
So that's a good point.
So you can actually have--
if you want to be a little more dynamic for some
of your businesses, you can have a fixed slot
for maybe the periodic jobs and the day-to-day requirements.
And then you can also add the auto scale here,
where you can have the additional slots spun up
for certain events.
So maybe you will have some daily current running
at maybe the first five minutes of every hour or whatever,
so that, probably, you would not want it invested in having
that fixed compute capability.
So you've got the mix.
It's literally, you look at the problems, [INAUDIBLE]
and then look at the kind of dynamic
that you want from a DevOps perspective
to a specific business team.
Similarly, I think we look at the auto scale on Bigtable.
That's also very critical.
And you can save a lot of money.
BRUNO AZIZA: I notice you have some reduction
in overall DevOps in Cloud engineering requirements.
Tell me more about that.
What did you experience, and how did you get to that?
RYAN DE MELO: So basically, what happens is like--
from our standpoint, from the Tokopedia engineering
standpoint, we want to be very lean.
And by lean I mean really keep as much of engineering effort
as we have on the front lines ready to go and pick up
the next big multi-million dollar or billion dollar idea.
And by that, it is about using services
that have been tried, tested, and being
used by customers similar to our size and maybe
thousands of them that exist across globally.
And keeping this principle in mind,
we invest very little in terms of infrastructure and DevOps.
In fact, like I said, our data engineering team was around 15
[INAUDIBLE] to 2020.
Considering the kind of scale we have, it's hard to believe.
But that's the reality.
And you do not want to--
so you can get these savings of almost 40%
cost reduction engineering efficiency
as long as you follow the best practices
and you don't start reinventing the wheel.
Now, that's very common, but we all know it.
But we end up doing it at some point in time
and realize that, hey, we need custom solutions.
But really, if you think a little bit deep
or you brainstorm with the data architects, the platform
architects, you'll get there.
And you'll understand the hidden gems
there might not necessarily be so obvious upfront.
BRUNO AZIZA: Well, that's an amazing journey,
15 people helping millions of products get to market.
And that was just an incredible data journey.
Thank you for spending the time with us today, Ryan.
RYAN DE MELO: Most welcome.
My pleasure, Bruno.
BRUNO AZIZA: And if you want to find out more about customers
just like this, make sure to click on the link down below.
Until next time, I'm Bruno Aziza.
[MUSIC PLAYING]