Real-Time Analytics at Scale: Kafka, Spark Declarative Pipelines & Sigma at DraftKings

Summary

DraftKings built a production real-time data platform processing hundreds of thousands of gameplay events and thousands of login events per minute using Kafka, Databricks Spark Declarative Pipelines, Delta Lake, and Sigma to power live dashboards across its sportsbook, casino, and daily fantasy verticals.
The architecture evolved from a v1 using structured logging and Elasticsearch to a mature v2 leveraging Delta Lake merge capabilities, liquid clustering, and Unity Catalog governance to achieve sub-60-second end-to-end latency.
A product-first mindset — prioritizing user outcomes, self-serve capabilities, and long-term platform thinking over short-term project delivery — was credited as the critical driver of rapid adoption and sustainable platform growth.

Real-Time Analytics at Scale: Kafka, Spark Declarative Pipelines & Sigma at DraftKings

Real-time analytics has transformed how DraftKings operates across its sportsbook, casino, and daily fantasy verticals. At scale, the company processes hundreds of thousands of gameplay events and thousands of login events per minute, requiring live visibility into transactions, active users, and financial metrics. this video covers how DraftKings built a production real-time data platform using Kafka, Databricks Spark Declarative Pipelines, Delta Lake, and Sigma to power live dashboards and decision support systems.
Learn how a product-first mindset enabled rapid delivery and user adoption, from initial proof of concept to multi-tenant deployment. The presentation details the architectural journey from a simple v1 using structured logging and Elasticsearch to a mature v2 leveraging Delta Lake merge capabilities, liquid clustering, and Unity Catalog governance. Attendees will discover practical optimization strategies for sub-60-second latency, late-arriving data handling, cost management, and scaling without code duplication.

Chapters

FAQs

How does DraftKings process hundreds of thousands of events per minute in real time?

DraftKings uses Kafka to ingest gameplay and login events at high volume, Databricks Spark Declarative Pipelines to process and transform the data, and Delta Lake as the storage layer. The final architecture pipelines data from Kafka through to Sigma dashboards with sub-60-second end-to-end latency.

Why did DraftKings move from Elasticsearch to Delta Lake for real-time analytics?

DraftKings' v1 architecture using Elasticsearch created limitations as scale and complexity grew. The v2 architecture leveraging Delta Lake's merge capabilities and liquid clustering provided more flexible querying, better cost management, and native governance through Unity Catalog, enabling the team to handle late-arriving data more effectively.

What is liquid clustering and how does it improve DraftKings pipeline performance?

Liquid clustering is a Delta Lake optimization that organizes data for efficient query access without requiring users to define static partition schemes. DraftKings used it as part of their v2 architecture improvements to optimize query performance on their real-time event data.

How did a product-thinking approach change how DraftKings built its data platform?

By shifting from project thinking to product thinking, DraftKings focused on user outcomes, self-serve capabilities, and building for the long term rather than delivering one-off solutions. This mindset shift was credited with driving 100% adoption of the real-time platform across teams and sustaining the platform's growth over time.

Full transcript

[00:09] Yeah. Uh welcome everyone. Good morning. Um a quick disclaimer. Uh by now you know the drill. It's day three. Um so the first two slides are mandatory slides um that we're going to show next. Uh this is the forward-looking statement from data bricks. Um and yeah request to please complete your survey. It's
[00:24] available on the app. It helps us as presenters. Yeah. So today we'll talk through how we build the real time intelligence at DraftKings using Kafka, Data Bricks and Sigma. Uh here's the agenda. We'll start with
[00:40] some quick introductions about myself and Monica, we'll talk about DraftKings, the scale we operate at. Uh and then instead of diving into the technical details, we'll spend some time on on the journey like what decisions we we took along the way. uh how we took a product
[00:55] ccentric approach here and then we'll uh round it out by talking about like lessons learned and and the and the road ahead. Yeah. Yeah. Okay. I'm Monica Christopha. I'm lead software architect at uh DraftKings. I have more than 17 years
[01:12] experience designing complex large scale uh systems. I specialize in distributed realtime uh data architecture and one of my primary focus uh at draft kings uh is the for detection and other real time
[01:29] architecture similar to that. Yeah. And uh I'm not paid. I lead the data product management and the QA function at DraftKings. Um over the last few years a major focus for me personally has been like shifting my team from working on data projects to building data products and a lot of it
[01:46] is centered around like product thinking in data like building uh self-s serve capabilities focus on user outcomes focus on adoption uh and building like capabilities for the long term for draftkings and uh as most of you here uh we're also highly focused on AI so uh a
[02:02] huge part of our job uh is also how can we systematically infuse AI into uh into the way data teams operate. Uh yeah uh about DraftKings um I think most people here are familiar with DraftKings. We are a digital sports
[02:17] entertainment and gaming company. Uh these are the four big verticals we have. Apart from this we have uh several other smaller verticals. Uh daily fantasy was our first vertical when we launched. uh and uh uh then we have our sportsbook vertical, a casino and uh
[02:34] predictions is our newest vertical which we launched in November of uh last year or December of last year. Um and each of these uh like from a data team's perspective um each of these product lines uh present different challenges. Uh casino and predictions uh they they
[02:51] they have like fa fairly stable environment in the sense that uh the the demand pattern is pretty stable. But when it comes to sports book and increasingly predictions uh the the demand pattern is uh highly variable. It depends on what happens in the game and from a data perspective uh we are uh we
[03:10] operate differently when it comes to serving these different product lines. Yeah. Uh before we go into the technical details just wanted to uh spend some time on the on the scale that we operate here at DraftKings. Uh you can see that there's u almost 11 million unique
[03:26] customers as of Q4. Uh but more interesting is what happens when there is a game happening. Uh uh when when a when a game like a Super Bowl or a championship weekend happens uh every layer of our platform is active. You can see we have like hundreds and thousands
[03:41] of gameplay events uh tens and thousands of login um thousands of deposits per minute and hundreds of registration. uh and uh when like for example just to take it further if there is a touchdown happening during the game or uh if
[03:57] there's a ad that goes on on air we see a a huge spike in key KPIs some of these KPIs and some of the KPIs are not here but we do see a huge spike in in in our key KPIs when when the game happens.
[04:15] Yeah. Uh so this slide really summarizes what we are going to talk uh for the rest of the session. Uh we start with the business context here. Uh we knew and this was way back in uh July of 2023. We knew that live betting was a strategic priority for DraftKings. Uh we also as I mentioned earlier we knew that
[04:31] demand patterns were highly variable uh when it came to our sportsbook vertical. Um and and then because of that we felt like operators would need better visibility into what is happening in the game. And this is in 2023. Back then like real time was not a big thing at
[04:46] least at DraftKings. Now today it's table stable stakes. Uh but then we we had a strong conviction that uh we needed to provide like real-time capabilities for our stakeholders. So we we we went ahead and started having some conversations with our stakeholders. Uh we the easiest route
[05:02] was okay have conversations get try to get some use cases um try to see like if they can uh imagine what a real-time dashboard would look like and what value they'll get out of it so that we can build from a platform perspective uh and when we did that like something
[05:18] interesting happened um when we started having conversations with stakeholders uh stakeholders were like hey we are happy with what we have uh and partly because they were weren't able to envision what a real-time data platform would look like um So at that time we made a product decision uh that we we
[05:34] because of the factors that I just mentioned we just felt like we had strong conviction that we had to build something a very hacky dashboard put it in front of stakeholders get some feedback and then drive adoption. So we went ahead and did that and um u the adoption was great like it it happened
[05:51] organically like uh year one of 2023 uh for the NFL season 1 we we launched the real-time dashboard and since then uh we we have a lot of users onto the platform now um and even like when we were initially building the platform we were like we had some use cases in mind from
[06:07] a data team's perspective uh but what happened was um when operators started using it more and more use cases came came forth which we didn't even imagine imagine in the first place. Uh and fast forward to today um we we have like several hundreds and thousands of
[06:22] dashboards at DraftKings built by analytics operators, engineers. This is the number one dashboard uh right now from an operational perspective. Uh and then this is uh this dashboard is used for all our tent pole events. Uh like we used it very heavily for uh Super Bowl
[06:39] uh two weeks ago for the NBA finals. uh this dashboard was used by uh a lot of the stakeholder teams. So uh before we get into the architecture and the technical decisions, I just wanted to take a step back and talk about the mindset that
[06:55] guided this journey. Um and this slide like we we try to capture what is the difference between project thinking and product thinking uh and the different dimensions where project thinking is different compared to product thinking. So with project thinking the usual goal is like deliver uh deliver the scope on
[07:11] time. Uh with whereas with product thinking it is like what value can you deliver to to stakeholders. It's not about like uh can you build this dashboard which is uh a project thinking mindset to whether this dashboard is going to be useful for operators. What value is it going to be deliver going to
[07:27] provide? How are operators how frequently are operators going to use it? Will they change their workflows uh based on the dashboard? And the one uh dimension that really resonates here with me is the team role. U in project thinking it's more around like a stakeholder comes to you they they say
[07:43] okay build me this dashboard these are some requirements. Here it's the other way around uh where the team decided to build the dashboard and uh they were thinking about why it needed to be built and what uh data points needed to be presented in the dashboard. Uh yeah can you go next slide? So just
[08:00] taking that step further and just wanted to show how we applied product thinking in practice. Uh the first thing we did was platform first as I mentioned like uh we live betting was a priority the demand pattern is variable. So we we were like okay let's build the platform
[08:16] first instead of solving for a single use case let's build a very hacky dashboard and then on top of that the new use cases will emerge. So we were confident about that. Uh second uh we wanted to validate the pull before before investing uh investment in terms
[08:32] of resources. Uh we had a single engineering team work on the initial dashboard uh investment in terms of tooling like we didn't know if the dashboard is going to be used in the first place by operators. So we didn't want to spend a lot of uh money using like newer tools. So we started and
[08:47] Monica is going to talk about that. So we started with whatever the team was comfortable with and wanted to get validate the pull before we actually uh committed resources and uh uh and money to it. And and the third one is uh the most important one uh because we had like an internal deadline of uh
[09:03] delivering the dashboard by NFL week 1 of 2023. Uh we shipped with known constraints uh in the sense that like when we started it was a single Kafka topic. um in several places we had hard-coded rates uh on the dashboard. Uh and we also knew that there was some
[09:20] variance um in in the data. Uh I know like when there's u variance like especially when you work for a data team we get very anxious if uh numbers don't tie and uh the executives also get anxious when that happens. So that was like we we either could take some time
[09:36] and fix like bring more Kafka topics in um fix all the issues some of the variance could be fixed uh whereas at that time but some of it is like the nature of real time is different from a batch KPI so a real-time KPI revenue
[09:51] that we show on the dashboard might not match what we show uh to Wall Street. Uh so at that time we were like okay let's the the value that we can deliver uh by putting the dashboard in front of stakeholders is far greater than the risk like if we take six more months of
[10:06] engineering effort to fix all these issues. So we took a very conscious effort to sort of document what the variance was, explain the variance, um, uh, create a how-to document, share it with stakeholders, uh, share it with leadership teams, and really say like,
[10:22] hey, if you're using the dashboard, you have all these caveats that you need to be aware of. So that I felt like was one of the most important uh, decisions that we took at that time. Uh, with that, I'll let Monica talk about the architecture revolution. Um yeah so as you can imagine the
[10:40] uh the solution did not start with the final architecture actually the first version was quite simple in knife in implementation it was supposed to connect the major pieces end to end expose live matrix to uh to our operators and see if having such a
[10:57] real-time data would change their behavior or how they react during the games compared to what we already have had establish published with um um dashboards on top of our warehouses and yeah the answer is yes the hypothesis
[11:12] was proven. Next one. So V1 was like a proof of concept disguised as a production service. Uh the design was quite naive. Uh it used structured logging as a data sync. Instead of writing to a proper
[11:29] database with absurd semantics, the service wrote uh city log and um it basically ended up in elastic search. Each uh process message was a dedicated new log line like like just writing to
[11:45] the to the std out except elastic search was indexing it. So this means that with that micros service we didn't have primary keys, no update capabilities, no delete capabilities, uh no uh no join
[12:02] capabilities and this was intentional because the team had a hard deadline. they had to deliver before the kickoff of the NFL which was uh in September 2023 and they just had little time to to implement and
[12:19] building a proper streaming platform with state management the duplication multiream joins would have taken quite more time than what the team actually had. So the team made a deliberate uh trait every output was disposable. We
[12:34] had configured um sevenday TTL on the on the index in elastic search and data literally disappeared. But that was quite okay because the purpose was to see if we can spot live trends, no historical analysis. We agreed that we
[12:52] were going to have like acceptable uh duplicate rates and nobody was actually making any financial decisions uh from those uh dashboards. So uh version one was never architecture. It was a validation
[13:08] experiment with the production SLAs. Uh but we decided that it made sense. It proved our hypothesis. So we wanted to build something better. We wanted to fix uh three major things. We wanted to be sure that reprocessing will preserve the
[13:24] data integrity. This was not possible with version one just because there were uh no Kafka replace any consumer reboundance directly inflated the KPIs. Second, we needed a unified view across multiple stream just because we have a lot of Kafka uh topics which share the
[13:41] the same state and we wanted to assure that we can actually handle late arriving data and out of order data. And last but not least, we needed a solution that can scale horizontally without cloning the code because before we had uh basically a lot of hard-coded data, a
[13:58] lot of hard-coded mappings within the within the microser and additionally a lot of hardcoded logic within the transformers. So instead of trying to patch, we decided to to fully replace it. uh this happened during the time
[14:13] when we already were uh using data bricks and we were on boarding more and more teams. So we decided to explore that option and see how it would compare to let's say a typical net service. And to be absolutely honest with you, of course, we could have built a better
[14:30] version with a .NET service um a net service that can basically handle all of this. But uh there are specific uh capabilities in Spark and Delta Lake that make um actually such solution uh easier to implement especially for teams
[14:47] that come from the data engineering and they are more um they have skills in SQL and um and Python. So I don't know things like denormalization and explode logic in spark where you have like complex nested objects and you
[15:03] can easily expand them into a flat uh analytical model or uh dduplicating within a microbatch. Those are really nice capabilities that came um for free for us. But critically I think and this
[15:18] is one of the major points why we decided to proceed with that is the integration with the delta lake because it provides capabilities that are genuinely really hard to actually replicate with the traditional tools. So things like merge with conditional logic
[15:33] uh liquid clustering time travel uh continuous optimize horizontal scaling all of these yeah they make uh such uh systems quite well designed and to achieve the same with a net u microser
[15:49] you would probably need a relational database with a careful partitioning and indexing or a purpose-built uh real time all up which It's sometimes can be quite complex to implement and the maintenance is not that easy and yeah the bottom
[16:05] line here is that any net engineer can probably build similar system but you are building to different system uh basically the operational streaming pipeline and then a separate analytical query layer with what we actually delivered with the spark and the delta
[16:22] lake. uh those for us are the same same system. The streaming rights and the analytical reads happen on the same uh storage governed by the same uh catalog quitable by the same engine and by the way supported by by the same team.
[16:38] So before we actually started designing the the final architecture, we wanted to give space for the team to explore data bricks, see how it compares to other thing that we uh we had already established at DraftKings and we give
[16:54] them like free time to do whatever they want. So the team tried exploring the native uh datab bricks uh tools like instead of starting with uh spark they decided to try dot uh which is I think
[17:10] the nature of starting point. It is the recommended data bricks path for streaming detail. Uh those are declarative pipelines um declarative pipelines um definitions. We have automatic reply building data quality expectation and it felt really good with
[17:29] with the team who was strong in uh SQL and Python. But as the as the system matured, we identified some specific uh configuration needs that we needed which cannot be achieved with DOT. So uh we
[17:46] wanted to control how often each stream processes like we needed zero post between the batches. We needed custom logic for handling the duplicates. Um we needed uh control over over the failure and um all of this made us move
[18:03] away and proceed with uh with spark. Then the team export uh Jupyter notebooks for production KPIs. uh the team started um basically implementing individual metrics and a standalone uh notebooks. So the the pattern was one
[18:21] notebook per KPI KPI. So handle GGR active user things like that. It turned out it was really fast to prototype, easy to iterate and feels productive until you actually have a lot of them and it becomes unmaintainable. So no
[18:38] inheritance, no easy way to test. Uh um it was really hard to update the logic once something changed. So yeah, our lesson here is that uh notebooks are quite productive for exploration, but production usually requires modular well
[18:54] tested uh code uh with shared abstractions. Then we let the team explore the cluster sizing. Uh we tried various configurations things like uh uh clusters from excess with uh two workers up to 2 XL with 64 workers. uh we tried
[19:12] uh the photon optimization which is amazing and what it turned out that such small changes actually reflect quite well in the latency and shows latency improvements but at the end of the day uh there is uh this cost um uh that you
[19:29] always need to have your eye on and basically adjust. So I think uh yeah uh we managed to balance the the latency against the call cost and still keep our uh SLAs's uh the way that we wanted them. And then last but not least uh the
[19:47] single stream for multiple event types. This is more related to how we decided to organize our code. But initially we wanted to have streams that read from Kafka topics and share the same uh the same state. So we decided to actually
[20:04] proceed with one uh pipeline and join them there share the state. But as V not mentioned we have a lot of spiky um load and sometimes uh every stream um let's say have have different expectations. So
[20:20] we want to scale independently and in order to achieve that we actually decided to split into multiple pipelines and share the states uh via merge into uh into the same delta table. So this is where we actually moved our state
[20:45] something happened. Yeah. Okay. So before I show you the final architecture, I want to share uh some of the scaling pain points that we had and here our datab bricks team was quite instrumental. So they were helping us all the way and not like you know just
[21:02] sharing documentation like real uh code reviews, code advis and yeah helping with everything. So the target here was it we were close to the to the next uh Super Bowl and we wanted to uh to basically adjust to the
[21:20] for the NFL Sundays and the and the Super Bowl ball load started doing a lot of load testing and it turned out as the volume doubled so did our compute cost. And the initial reaction of course we wanted you know just because we wanted
[21:36] to handle that load we wanted to scale up but datab bricks team actually said stop and let's see what we actually have. So they helped us analyze the sparkot the cluster and the latency expectation and based on that we scale out uh properly. As you can imagine
[21:53] having futon enabled it's quite expensive. So depending on your use case um yeah decide if this makes sense or not to have it enabled. Then they helped us identify that actually our merge scans were was the um our merge scan was
[22:12] our dominant cost uh driver and if they helped us enable the liquid clustering on specific merge key which actually reduced the sky time without uh scaling um and having more workers. Then next we
[22:28] had uh um our optimized job moved to into a smaller cluster outside of the standard uh streaming resources. So that way they didn't compete and then uh la last but not least they looked at um our
[22:44] uh pipelines and advised us because some of the pipelines actually do only appendon rights while others do merge. So depending on what kind of pipeline we had we um yeah we basically scale differently. Next late arriving data
[23:02] this is like a correctness problem and yeah as I told you a lot of Kafka topics we need to merge them and uh because of that uh we needed the same uh logical entry with u and the cafka topics didn't
[23:17] guarantee any delivery order. So what we did is that we uh with the help of the data bricks team we did um duplication and um we adjusted the logic at two places. First within the uh within each
[23:33] batch uh of the spark job. We uh basically looked at the records we ordered by time stamp and whenever we saw something that was duplicated we basically drop it and uh across the batches. This actually happened to the in the delta table we had three
[23:51] different merge checks. So uh we check if it's the same record if uh the record had the same payload and if whatever we have seen in Kafka is at least as fresh as what we already had in the in the delta table and based on that we either
[24:07] update insert or just keep the record and then the latency issues you I feel like this is one of the most common problems but yeah uh our SLA was we wanted to have a sub 60-cond end to end
[24:24] architecture. So from Kafka to the sigma visualization and it seems generous but it actually it's not because once you actually start counting the hops you see that you have the micro branch processing time the delta right the optimized compaction the SQL warehouse
[24:40] query execution and the sigma refresh. So all of this it's into your budget. So the data team uh helped us a lot improving the latency here as well. Uh before in the spark job we were using uh hash joins for our uh reference tables
[24:56] which actually involve uh network shuffle. So they advised us to use uh broadcast joints which yeah basically remove the network shuffle. Then in the uh in the right part we use the with their help we configure the max batch
[25:13] size. So the batch is not large enough to eat from our um SLA budget from the latency but uh small enough in order you know to meet our uh expectations in the query layer. uh basically before we were
[25:28] using classicing compute uh for the SQL warehouse we migrated to the uh serverless to avoid the code start problem and in delta with the liquid clustering which basically meant that we didn't have to scan irrelevant data uh
[25:45] while uh doing the merge because the data was already located by a merge key and um last the small file problem this is a classical uh streaming on lake challenge. Every microbatch writes small files over the hours. You accumulate a
[26:02] lot of uh tiny park files and read performance starts degrading exponentially because the query engine opens each of those files and reads them independently. So here yeah we saw the most improvements because uh datab
[26:17] bricks team helped us figure out exactly the optimal cadence that we needed in order to optimize efficiently. So for us it turned out to be every three minutes. Uh and um this way we um
[26:34] we found our sweet spot between the read and write um ratio. And another tricky thing that they helped us with was the time semantic rework which initially so initially we were writing them the trigger intervals uh that produced too
[26:51] many uh files per batch. So what we did is uh for each record in the stream we took the records time stamp we rounded it down to five minutes and this is how we actually rounded it uh write it uh into the delta and then we partitioned
[27:09] based on that uh time window and because of that we were able to really fast answer questions like um give me the data from the last 30 minutes and this way we scanned only six folders instead of scanning running uh thousands of
[27:24] scattered files. And this is where we ended. From left to right, we have Kafka, Spark, Delta, the optimized job in a dedicated cluster, the uh serverless warehouse and the
[27:39] sigma. So, uh the spark job is doing a lot of things. It d serializes the JSON. It joins with the reference tables. uh it's they normalize the Kafka uh messages into a flat analytical uh row. They
[27:55] duplicates within a batch using a special row number and then executes merge into the target delta. Then in the delta lake basically this is where our data lives. Um it uses liquid clustering. We use unity catalog uh that
[28:12] govern the data. Then it's the optimize job. It runs every two minutes in an infinite loop and uh with ret with retry logic and it's not on the streaming uh path but we also have a batch path where
[28:28] uh every 15 minutes uh we basically pull reference data from snowflake using the spark snowflake connector. This brings us um this brings data like jurisdiction, customer level, market uh types and year and special data like
[28:46] year-to-year pacing and some data science uh forecast. So this way we can enable uh in sigma dashboards as actual actual versus forecast views which we couldn't support before. And then as I mentioned we have the uh serverless SQL
[29:03] warehouse which executes the queries and then finally the sigma layer the our vis visualization uh layer which connects really easy with the datab bricks. So basically there is um um whenever an operator opens a dashboards that
[29:20] dashboard generates a SQL query which is sent over to the uh SQL warehouse over HTTPS. um the warehouse execute the query uh goes through our data tables return the result and then we have the result back
[29:35] to the to the sigma dashboard. So yeah this is uh the architecture that we learned and I want to finish my part with five lessons that we learned having you know delivering that architecture on
[29:50] production. So the first is that people don't realize the power of the fresh data until they actually experience it. Nobody or just a few people before that um that project asked about real-time analytics and once we hit the NFL week
[30:08] one operators were managed they basically have the tool which allow them to see spiking higher than expected in some KPIs. Our marketing team was able to adjust the promotions live the traded to the to the signals on the uh in the
[30:26] exact time. So basically this gave them a tool to react within the the window that we have during the game instead of reacting on the next day. Uh the next thing is late uh data matters more than you think. Uh in batch systems you never think about that or
[30:43] you rarely think about that and late data is just a mild annoyance. But with real-time data you basically have your um your KPIs wrong, your metrics wrong. So if you want people to trust whatever you build, you always needs to start
[30:58] designing having late data and out of order data in mind. Uh next is small teams um small experimentation teams move faster. All of this was built only with three core engineers and why this matter is that we
[31:14] gave them the space to learn to explore. We had uh fast feedback loops. They knew at some point what would work in our use case and what not and at the end they basically can debug and figure out any issues that that we had. So I think in
[31:31] that particular case ownership beats the headcount optimization save massive costs. I think it's clear always monitor what uh what you use how much data you process and adjust and always think how how you can optimize and keep the cost
[31:48] flat. And I think the last thing is one of the key thing that I think it's important for our presentation is that the product plus um architectural alignment matters and my experience is that sometimes even the best architectures fails if nobody uses them
[32:05] and we have seen examples where even the wrong architecture architecture gets adopted just because there is the right product thinking. Our V1 was really kn simple in implementation but it had the perfect product alignment and it was
[32:21] shipped exactly on time. So we gave a tool to our operator and they knew um after that it basically changed their behavior overnight. So I I think you always need to use your product and work together.
[32:37] Yeah. Cool. Uh yeah, we we spent a lot of time talking about architecture, the the decisions that we took, the lessons we learned. Um wanted to round it out by like talking about business impact. Uh on the right you can see like quotes from our stakeholders who use the the
[32:52] dashboard uh every day. Um and on the left you could see like when we started week one of NFL uh 2023 like we we had very few users in the first month. Today as I mentioned before it's like the number one uh dashboard uh in in the draft kings ecosystem. Uh we started
[33:09] with sportsbook uh that was our initial uh use case but then like traders saw that uh the sports book is using it and so they were like we needed something dedicated for trading. So we built trading dashboards. Uh Pix was a product which that was launched a couple of years ago. Uh they saw the sportsbook
[33:26] dashboard and they were like hey we would we would need this kind of a dashboard for Pix. So uh all on the same platform we we have three uh sort of different kinds of dashboards live uh and and the main validation I would say is like not just uh stakeholders using it but uh when we sat with them and and
[33:43] saw how they were using dashboard we we were actually surprised to see that they've actually changed their workflow uh based on the availability of real-time data. Uh yeah so one of the advantages of building a platform is the the road map uh reinvents itself. I mean it it just
[34:00] makes the easy in terms of uh stakeholders start using it and so the the road map presents itself. Um and so we are looking at uh uh three different uh areas of expansion. One is for all the existing uh uh dashboards that we
[34:15] have uh how can we add better features to make it easier for our uh stakeholders. So you you can see some on the on the left there listed. Uh we are also as I mentioned we we have uh three products uh live uh but we're also thinking like predictions was launched
[34:31] last year. We already have something in the weeds for a predictions real-time dashboard that's going to be out soon and we're also explor exploring and even even some of the other uh product lines where the demand pattern is not variable. We're also exploring if it makes sense to uh build real-time dashboards for for newer verticals. And
[34:48] then like from a the most important part would be like a platform and architecture piece. Uh as Monica mentioned um we just had a team of uh an engineering squad build these dashboards. Uh we know it's not scalable. So we want to make sure like we make real-time data assets available
[35:04] to everyone in the in the arc. Uh just like all the other data assets, analytics operators, whoever wants to build dashboards, they can go ahead and build it. Right now it's not scalable like we we just have a team of uh four building it. So we want to make real-time data assets available. Uh
[35:20] we're also uh like on on Tuesday there was an announcement about Raiden. So we're we're exploring Raiden, we're exploring Spark in real time and we that we believe will help us uh provide better visibility, reduce latency, reduce cost as well. Um and yeah uh I
[35:35] think like um uh DraftKings is big on AI and and so we feel that uh the combination of real-time data and AI is going to be particularly exciting. Uh so that's also uh one key focus area for us. So while while we um have spent most
[35:51] of the time talking about what we accomplished here like with all the uh technical improvements with all the capabilities that are being released by data bricks we feel very excited about the the road ahead. Yeah. So uh that's that's it like we uh
[36:06] TLDDR is we built the platform and then the use cases found us. Yeah. Uh thank you. We can we can take questions.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.