Suman Karumuri has spent 17+ years building observability systems at Amazon, Twitter, Pinterest, Slack, and Airbnb. He was tech lead for Zipkin at Twitter, co-authored the OpenTracing specification that fed into OpenTelemetry, and has now replaced Elasticsearch twice at high-traffic platforms. In this episode of the Smooth Scaling Podcast, Suman walks host Jose Quaresma through KalDB, the open-source, cloud-native log search engine he is building into a product, which runs at petabyte scale at Slack and Airbnb. They get into why he keeps rewriting Elasticsearch instead of tuning it, how separating compute from storage on S3 changes what a log system can do, and the recovery-task trick that keeps fresh logs visible when volume spikes 10x. The back half turns to agentic AI: why agents querying logs in unpredictable bursts break traditional log stacks, why you can't sample data anymore, and what engineering leaders should measure before the bill explodes. A concrete, in-the-weeds look at running log search when the primary user is no longer human.
Suman Karumuri is the founder of KalDB, the open-source cloud-native log search engine he is now building into a product. KalDB runs at petabyte scale at Slack, Salesforce, and Airbnb. He spent 17+ years building observability systems at Amazon, Twitter, Pinterest, Slack, and Airbnb, was tech lead for Zipkin at Twitter, and co-authored the OpenTracing specification under the CNCF, which became the foundation of OpenTelemetry. He is based in San Francisco.
Suman has replaced Elasticsearch twice at high-traffic platforms. And with the rise of Agentic AI querying log systems in non-deterministic bursts, this places a whole new kind of stress on those systems to perform at high scale.
Episode Transcript
Jose:
Hello and welcome to the Smooth Scaling Podcast, where we speak with industry experts to uncover how to design, build, and run scalable and resilient systems. I'm your host, José Quaresma, and today we had the pleasure of chatting to Suman Karumuri, who's the founder of KalDB, after having been a principal engineer at Airbnb, Slack, and others. We had a great conversation with Suman about building KalDB. This is a cloud native log search and analytics engine that is built for high-volume observability workloads. We discussed the complexities of scaling observability in huge operations, as well as catering for the two main use cases when it comes to logs, search and analytics. Finally, we addressed the new challenges that agentic workloads bring to the observability world. If you like this episode, please subscribe and leave a review. It really helps the podcast. Enjoy. Welcome, Suman. It's great to have you on the show.
Suman:
Yeah, thanks, Jose. Thanks for having me here.
Jose:
And I would like to dive straight in and would like to start by asking about the origin story of KalDB. Can you take us through how it all started at Slack?
Suman:
Yeah, so the origin story of KalDB goes something like this. I've been working with observability, running observability systems and log search at very large scales at a lot of companies. We actually built, I used to maintain the Elasticsearch cluster at Twitter back in the day. And back then, Elasticsearch was causing us a lot of issues. So we actually built an internal version of Elasticsearch based on Lucene. At that time, we didn't open source it because we didn't think much of it. But this was way back in like 2014. And a few years passed and I went to Pinterest. And at Pinterest, I saw that Elasticsearch had the same issues. And then I was at Slack and I saw that Slack also had the same issues. And initially, I built tracing at Slack. And then we were looking at logs as the next big thing, but improving Elasticsearch, having done that several times, what I've realized is it's just better to rewrite it. So again, I started the project to rewrite Elasticsearch in open source. And that's how we actually got started. And that's the origin story of KalDB. One of the things we wanted to solve especially was, we wanted something that is cloud native, where we had a separation of storage and compute. We still don't have an open source version of Lucene that has a separation of storage and compute. I mean, open source, these systems have some flags and stuff like that, but it's not very easy to use. The second feature we wanted was the ability to run on Kubernetes very easily. This was also not very easy in Elasticsearch. Part of the reason is when you actually add and remove capacity, Elasticsearch and OpenSearch, they actually reshard the existing data and change the cluster a lot. As a result, the cluster takes a long time when you add capacity to get to green from yellow, right? And this was the second problem we wanted to solve, where when you actually add and remove capacity, you didn't have to wait a long time. And the third thing we wanted was, one of the third problems we had was sometimes it would get like 10 times more logs. For example, let's say all our applications in Slack talk to MySQL. Let's say MySQL is down, right? Now, all the applications are logging pretty much the same log to MySQL sometimes. And the amount of volume you need to catch up is like 10 times. And what used to happen at Slack is our log search was behind by 12 hours. Sometimes it would take 10 to 12 hours for the entire volume to catch up. And during that time, we would lose our visibility from logs because the cluster is behind. So even if you put in a fix, let's say an hour after, from the logs you won't know whether the fix worked. So this was a major issue that we wanted to solve. And we also wanted additional retention, we wanted to reduce the cost, keeping logs on S3, and these were like other side quests we wanted to chase. And because of all of these, we looked at this holistically and we said that we need to solve this problem in a holistic way. And having prior experience from doing this at Twitter, we decided to rewrite Elasticsearch from scratch, and the birth of KalDB. But we also had a lot of workloads that were already running on Elasticsearch and OpenSearch. So we wanted to keep the same API as well. So the way to think about KalDB is it's the same read and write API. So from the outside, it looks like another Elasticsearch or OpenSearch cluster. But internally, it's a completely different implementation of Elasticsearch that is serverless and more scalable.
Jose:
And why, I have a lot of questions and I hope to get through them all, but why was the requirement or the idea to keep the same APIs? Is it mostly from a migration perspective? Was it more around making it easier for everyone that is already using Elasticsearch? Was that some of the motivation behind it?
Suman:
Yeah. So we had a lot of users who are trained already on Elasticsearch APIs and queries. So we didn't want our users to relearn a new API and a new way of using the system. And also, the other motivation was we didn't want to do a big migration of data from one system to the other, making sure it's all correct, things like that. We also avoided that by keeping the API the same.
Jose:
I guess you already gave us the definition of KalDB, but just for people who are not familiar with it, could you just repeat it in the elevator pitch, the one sentence for KalDB? How would you explain or define it?
Suman:
The simplest way to imagine KalDB today is it's a serverless Lucene implementation of OpenSearch. This is the only open serverless implementation of OpenSearch.
Jose:
And I understand that one of the big ideas in KalDB is to separate, as you also talked about, the compute from storage, right? Can you share a bit with us why, maybe go a little bit one level deeper with some examples of why that's important? And what does it let you do that Elasticsearch doesn't?
Suman:
Yeah. So the idea of separation of storage and compute, it has many manifestations in practice. The main one is, currently, if you use Elasticsearch or OpenSearch out of the box, you actually have to use local disk to store the data. So one of the problems is, let's say you add additional capacity, you have to move the data from this disk to a new disk, right? And that takes a long time. And also, let's say this machine dies, you have to copy the data from this machine to another machine, or you have to run a replication algorithm to replicate the data from this machine to the other set of machines, right? Whereas in a compute storage separation, you would actually use S3 as the primary store of the data. So every time you write the data, you put that data in S3, and that is your store of durability. So what happens is, in a compute storage separation, your local node becomes effectively stateless. If the node goes down, you don't have to create more replicas of the data or anything like that. And it also gives you a lot of other advantages that are needed in general. For example, because you're using S3 as the storage, you don't necessarily need to take any backups of the data, right? If you use local disk, you have to actually use S3 for backups. So your operations become much simpler. The other advantage of this compute storage separation is, let's say you have a single node and you want to create, let's say, 20 or 50 or 100 replicas of this data because you have that much read load, right? In a regular disk-based system, if it's a single node replicating the data to, let's say, 20 replicas or 50 replicas, you would very quickly saturate the network bandwidth, and then a lot of latency and all of those issues. But if you use S3, what ends up happening is, let's say you want to bring up 100 replicas of your data, you would bring up 100 nodes and they would just copy the data from S3 in parallel. That way, you actually add effectively a lot of throughput. And this is not just true of a search system or KalDB. Any system that has compute storage separation has this property that whenever you scale up, you can actually bring up replicas without affecting the primary node that is indexing the data. And also, there are other advantages of compute storage separation. Like the latency of your reads is not affected while the replicas are doing their thing. Usually, without compute storage separation, you'll see very wide-ranging latency, especially if you are an e-commerce application or something like that. Latency is really bad because people are trying to search for items and these operations complicate your latency story quite a bit, and it's very hard to plan. So KalDB's compute storage separation helps with that.
Jose:
And is it also, and I could be wrong here, but I'll ask it anyway. You also mentioned in the beginning, you gave an example, I think at Slack at the time, that if something is down, you would have a backlog of logs to be processed that could take 10 to 12 hours to go through, so that they would be available on your observability system. Is having the compute storage separation, does it also allow you to more easily scale up the compute part to process all the pending data? And would that make it faster, I guess? Is that an advantage as well?
Suman:
Well, that's a great question. So compute storage separation historically has been with reads. But we actually write our data into Kafka as a write-ahead log, and then we index the data. The way we solve that 12-hour lag problem is, whenever we are behind by, let's say, a configurable amount, what we actually do is, KalDB has this internal mechanism called a recovery task. What that does is it says, hey, I'm behind and there's no way I can catch up on my own, right? And it creates what is called a recovery task, which is a high-powered indexer that actually comes up and indexes the data in an asynchronous fashion. And the current indexer is indexing the data that is fresh. That way we solve two problems at once. So the first problem we solve is, when you're behind, there is no point indexing old data. We actually start indexing fresh data. So you get real-time visibility right away. And in a little bit of time, we actually catch up in about 10 minutes or 15 minutes. And this is basically compute storage separation applied to write. We are the only system that actually does this today.
Jose:
So at some point, if you look at your observability system, you'll be able to see the logs in the last one hour. And then maybe there's a gap while the system is catching up, but then at least the freshest stuff, you have it straight away.
Suman:
So you won't lose that visibility. These are the features you would get using KalDB, where you don't have to wait for 12 hours for the system to catch up. I mean, I've had enough sleepless nights where I was just waiting for it to catch up. I was babysitting it to make sure it's not going down.
Jose:
That's very cool. That's, I think, a very interesting and useful approach. So, okay, can you, to help us make it a bit more concrete, take us through the journey of a single log message through the system?
Suman:
Yeah. So the way the system works is, typically you have Logstash writing to Elasticsearch, and then the clients are reading the data, right? That's the architecture. In our system, similarly, you configure your Logstash to write to KalDB. Logstash wouldn't know what it's writing to. And then KalDB has a component called preprocessor, which basically decides which indexer the data has to go into, right? And this is another feature of KalDB, where we separate the preprocessing of the messaging from the indexing. Because one of the things that happens in Elasticsearch or OpenSearch is it's the same node. So if somebody is actually writing a lot of messages to you, even though the messages are rate limited, the node actually runs out of memory or runs out of connections. But in our system, we actually separate that. The preprocessor helps you with that. It also helps you make sure the messages are of the right size and the right format and all of those fun things. And then we actually write it to a write-ahead log. Currently, we use Kafka, but you can actually use any similar system. And then there is an indexer that indexes this data from Kafka. And periodically it reads the data and then it snapshots the data to S3 from the indexer. And when the snapshot is done, the data is on S3. And then we have a cache node which downloads this data from S3 and it can serve it. And then we have a query layer on top, which actually implements an OpenSearch API. And this query layer handles the incoming reads. And it figures out what data needs to be queried, does a scatter-gather aggregation, and returns you the data.
Jose:
You did take us through the whole flow. So what would you say makes KalDB special, or what distinguishes it? Would you put the preprocessor in that area of something that is not usually seen, or is it more the dual layer that we talk about?
Suman:
So the parts about KalDB that make it unique, I think — the compute storage separation and things like that are obviously being added to other platforms as well. The unique parts are recovery tasks, where we can catch up. If you can scale up elastically, up and down based on the load, that's a feature that is very unique to KalDB. The other aspect that is very unique to KalDB is this separation of metadata from the actual main system. Today, we actually use an external metadata store instead of just Lucene in OpenSearch. That helps us actually scale to petabytes of data. Today, Lucene or OpenSearch generally tops out at around 200, 300 terabytes of data. Once you have a cluster that size, it becomes really hard to manage, or operations are very slow. For example, we have seen some clusters, some customers, where just to upgrade the operating system takes six weeks in their Elasticsearch cluster or OpenSearch cluster. Whereas we just have that process so smooth that for somebody running KalDB at Slack or Airbnb, it's a non-event pretty much. Like operating Kubernetes clusters is a non-event. And I think the biggest claim to fame is we actually run at petabyte scale. So today, if you have a petabyte of log data, it is really hard and really expensive to run it. KalDB is currently the only serverless platform that makes it easy to run a petabyte of log data, logs at chat scale.
Jose:
Thank you for that explanation. And I would now love us to talk about the agentic AI part and the AI era, so I'll make sure that we have time for it. But before we get there, I just wanted to talk a little bit about the alternatives to KalDB, and you've shared a little bit. And maybe starting with the question around ClickHouse, right? That is right now the trendy answer for log analytics. Why don't you just use ClickHouse?
Suman:
Yeah, so that's a great question. So first of all, most people who are running log search were running it for search, not for analytics, right? So at least when we started, ClickHouse did not have search. They actually just added search, I think, sometime this year. That is one reason. So if you want search, we didn't have any other options. The second thing is, when you actually come down to the workloads, if you have highly structured data, ClickHouse is really good. It shows up really good in benchmarks, right? But when you have semi-structured data, which is actually a lot of log search data, ClickHouse is not as easy to run, or at least has performance issues. And so that's one way to think about it. ClickHouse now added some amount of search capabilities, which is true, but its search still kind of pales
Jose:
a little bit in comparison, right?
Suman:
The other thing to remember with ClickHouse is one size does not fit all. So even if ClickHouse works for some use cases, it may not work for other datasets. For example, if you have security logs or kernel logs where you're doing needle-in-a-haystack kind of search, ClickHouse doesn't really work for that. Or if you have a customer support person who is trying to query your logs and they don't know what to look for, right? So they don't have that absolute perfect SQL query. They're just saying, customer gave me this error message, I'm going to stick this error into the text box and see what comes up, right? So for those kinds of use cases, search is still better. And people also compare, like, oh, ClickHouse is more compressed, but Lucene is more verbose, right? Most of that comes down to data structures. But even when you're on ClickHouse today and you're doing search, you're basically implementing the same serialized data structures to disk. So the argument that it's going to cost less in disk, all of those are kind of not valid anymore, because you want search, you want the search data structures, and you'll pay for those search data structures, which is roughly maybe 20 to 30% of your raw data size. So in some sense, these are different use cases, I would say. And also, with ClickHouse, if you want serverless ClickHouse, you actually don't have that in open source today. You actually have to go buy it from ClickHouse. So even if you want S3-native, S3-optimized ClickHouse, you also don't have that. If you want serverless Lucene, you don't have that in open source. We are kind of the system that's trying to do that.
Jose:
And do you also see teams using both together? So you use Elasticsearch for search and then ClickHouse for the analytics.
Suman:
Actually, that's the pattern we see. Having worked in all these observability companies and having gone to a lot of conferences, that's the pattern I actually see, which is people actually writing the same data to both systems and doubling the cost. That actually leads into one of the features we just added called the polystore, where we started actually doing that in KalDB itself. Now, in KalDB, we added a columnar storage engine and we can index the data both ways. So for some datasets, you can pick Elasticsearch or Lucene as your storage mechanism. And for some index, you can actually pick columnar as the mechanism. And if you're feeling generous with your credit card, you can actually do both.
Jose:
When would people then choose one or the other? What are the guidelines there?
Suman:
Currently, it actually depends on the query pattern and the data format. If your data is semi-structured and your query is primarily search, you would pick Lucene. If your data is very structured and you're doing analytics, you would pick the columnar store in KalDB.
Jose:
Okay.
Suman:
Yeah, that's the enhancement I did in the last few months, actually.
Jose:
Okay, very good. And I think often when talking about logs and observability, one often goes into talking about traces as well. Does KalDB cover that as well, or is that a separate system?
Suman:
No, we actually have native support for traces. It's already deployed in production at Slack and Airbnb, where they actually store traces and serve traces from KalDB. So we support the same API. From a Grafana perspective, we just look like a Zipkin cluster. You configure it as a Zipkin endpoint and then query our traces, and they all show up in Grafana. And we also have native support for tracing JSON, OTLP traces as well.
Jose:
Very interesting to hear about. So thank you for taking the time to share. And as I promised, I would like us to go a bit into the agentic AI world. And I would start by asking, how did you see the AI agents coming in? How do they change the picture for observability?
Suman:
Yeah, I think the entire field of observability is going to change with agents. First thing is, till now, observability systems are built somewhat like this. You ingest the data using a collector, you store it, and then you have a UI in which you have dashboards and alerts. And what you would have is, a team sets up these alerts, and then some alert fires and somebody goes, looks at the alerts, looks at the dashboards, tries to diagnose the issue, and then puts in a fix. And this is all human-driven, and it's very reactive, right? You only do it when there is an issue. And this is where the discussion of known knowns and unknown unknowns comes in, right? Because with these dashboards-and-alerts way of looking at things, you're only looking at things that you know will fail. There are things that you don't know will fail in different ways, and you're not on it, right? With the agentic world, I think observability is changing. These days, nobody wants to look at dashboards or alerts. You just want to point an agent at an observability system, and you want the agent to automatically diagnose what the issue is, figure out, and give you a root cause. That, I think — when I talk to a lot of my friends in observability, that's becoming the trending pattern. And I think that pattern is here to stay, because that pattern is no different than when I'm coding and writing code using Codex or Claude. When I'm writing code using Claude, I'm actually asking it to implement something, run a unit test, look at the logs, and then figure out what's wrong and put in a fix, right? In production, this is pretty much a grandiose version of that, I think. So observability is moving from being primarily human-driven to agent-driven. And when it becomes agent-driven from human-driven, everything changes about it. Like, UIs don't matter, right? First of all, because agents only care about APIs and data. They don't really care about UIs. So that's one difference. The second difference is agents don't sleep and they're not very reactive. So you can actually be more proactive in your observability. So it changes how you observe your systems now. Instead of having alerts — yes, you'll still have alerts, but you can actually have more proactive alerts. Previously, let's say you didn't have any bandwidth to investigate those small errors that only happen once in a while. Now, before I go to bed, I can say, hey, go look at these logs and tell me why these errors are there and let's see if we can fix this. We couldn't do that before. And now the agent can actually go to an observability system and say, hey, give me all the errors in the system that happened the last day, and then go back and fix those issues.
Jose:
Yeah.
Suman:
That's the second way. And the third way I think observability is changing is, observability was relatively not a must-have in the older systems. It was mostly, I wouldn't say an afterthought, but it was not considered tier 1 or tier P0. It was mostly P1. But I think with agents, most people actually capture traces, agent traces, that are needed to understand what the agent did and why it did it, right? So in that fundamental way, with agentic observability, the amount of data you're storing is going to increase. Previously, if it's traces, right, I would just sample some traces, maybe 10% of my data, or, sorry, 50% of my data. But I can't do that anymore now. I have to keep all the traces, because every trace is unique and LLMs hallucinate, and customers saw something, so I need to be able to explain what they saw and why they saw something, right? The way the data is changing is also changed. Now I have a million-token context that I'm going to insert into the log messages. So my log messages are megabytes in size as opposed to before. So the data size is changing. Then the way this data is accessed is also changing. For example, I have some friends who have this prompt where they basically go through their agent traces and then they want to tune their prompt, let's say every month. They want to run an agent that gets their prompts and then goes and updates their code with a better prompt, right? And those workflows, at all the companies, because of cost, you only keep, let's say, seven to 10 days of data. But now if I'm updating my prompt every month, I need to have a month or two months or at least a quarter's worth of logs. So that is another dimension in which the number of logs you're storing has increased by an order of magnitude. So you can't sample data anymore. You have to store data for a longer time. You're accessing the data in a very different way, in a proactive way. And also, with agentic observability, when an agent queries, it actually queries very broadly. So it's actually doing 10 to 100x more queries than what you would see. And it's also doing very different queries that a human would never do, to explore the data and understand where the issues are. So the way in which your data is used is completely different in this new world. Observability became P0. The way the data is accessed is different. Who is accessing the data is different. How they are accessing the data is different. So everything about observability is changing, I think, in the new world. So it's an exciting time for observability in some sense.
Jose:
Yeah, it is. And I really liked that you mentioned all the different layers. But the one that I recognize from other areas, a bit of a pattern, is around the fact that us humans will move towards not really interacting with the dashboards, but interacting with an agent, right? So it's the whole concept of chat as the UI, and that in the future, every single product, it's a chat box that you ask, right? I think I heard it for the first time from Des Traynor, one of the co-founders of Intercom (now Fin), quite a few years ago. So I think it's a really interesting concept to keep in mind. Can you help us make things a little bit more concrete? So let's say that I have five, 10, 100 agents that are querying my log database. And as we talked about, it's most likely in unpredictable ways, at least in different ways than before, if it was five or 10 or 100 humans. What would you expect to be the first thing breaking in a traditional log stack?
Suman:
So the first thing that will break is probably the auto-scaling bit, or how the log system scales. Log systems or trace systems are not designed for these elastic querying workloads. So you actually want to have multiple replicas of the data so you can actually serve queries. So you want a database that elastically scales with the read load and maybe scales to zero when there is no read load, right? I think this is the first thing that breaks. If you don't have that elastic scaling capability, you always have provision for peak capacity, which could be 10 to 100 times more expensive than regular systems. I mean, log search is already somewhere between 5% and 10% of a company's budget, right, depending on how you're counting. And if you have to scale it 10x, now you're in for a budget. And I think that's not sustainable. So something has to give. And I think the thing that will happen is these systems will become auto-scaling over a period of time.
Jose:
And how does KalDB address that?
Suman:
Yeah. So remember I talked to you about how the cache nodes can scale up and down using S3. So with the compute storage separation, because the data is in S3, as the load comes up, we can actually increase the number of replicas serving that data. And as the load goes down, we can reduce the number of replicas serving that data elastically, so that you don't have to worry about it. And if there are too many agents that are writing a lot of data, we can actually scale the indexing elastically as well. So you can scale the writes and the reads elastically in KalDB today.
Jose:
I guess we also covered the cost part, right? And at least one of the aspects is that, well, if you don't have that scalability, you're either paying on the performance side, or you're paying with your credit card by always having to be scaled for peak, right? So if we have any engineering leaders that are listening to the podcast, and they think, okay, I have this issue — how should they be approaching this? What should they be looking at, assessing? What should they be doing this year, maybe, or next year?
Suman:
Yeah, I think in the short term, they should plan for observability to be a P0 item. I feel like most people are adopting different solutions that are much more expensive. But I think they should go talk to their observability teams and see how they can use existing observability systems, because those teams know how to monitor and how to make these systems very cost-effective. I think that's the first one. That way, you are not adopting lots of new systems, but you are getting more value out of your existing systems. The second thing is, it would be good for the leaders to understand how their workloads are going to stack. If you actually look at how their log volume is going — most people today think that I'm going to do what I was doing before, which is throw away data and things like that. But I think what they will see increasingly is, as autonomous agents become more and more common, they can't throw away data, because the agent cannot know what happened, at which point it cannot act on its own. So they need to have a tiered system of what logs are needed, how to access them, and when to access them, right? And today, doing that is very complex, and that's why we are building KalDB as a polystore, where they store their search use cases in one store and analytics use cases in another store. If your logs are cold, we actually even have a flat-file-based system to store the data and serve it. But if you don't have a system like this, you usually want to build something like this, where your agents have access to all of your logs in a very easy fashion, so that they can do agentic debugging. I think logs are going to be very important in the future, especially if you want your agents to autonomously take actions against your infrastructure. Previously, humans looking at dashboards kind of filled that role, and there's a lot of knowledge there. But now I think all of that knowledge is going to go into the skills files or runbooks or wikis or whatnot. And then these agents are going to look at logs, take your context, and then take an action. I think the infrastructure is evolving towards that, and whoever is looking at this should look at it from that perspective.
Jose:
That was, I think, some very good ideas for the engineering leaders out there to start approaching it. And maybe, I think we're getting closer to the end. I have still a couple of questions, and we'll get to some rapid-fire questions at the end. But one thing still following up on what the engineering leaders should do, right — I think maybe one of the concerns there, one of the main reasons for having a burning platform in this area, is probably the cost that we've talked about. So would you also have any suggestions on what leaders should start measuring to get a better idea for where that budget is bleeding into?
Suman:
I think measuring the ability to automate your platforms using observability data would be one of those. Like, can I use the observability data to have agents make more decisions? That would be the thing you should measure. Because I think over a period of time, you want to automate your operations. And the only way to automate your operations is to take advantage of the observability data. And once you start taking advantage of it, you'll see a lot of gaps in your current infrastructure, and you'll see a lot of gaps in what data should be captured, what data can be thrown away, what data agents need. Getting that balance takes some time, and I think that's what they should measure: what percentage of my day-to-day actions can I automate using observability data.
Jose:
You kind of moved to invest yourself in KalDB in the last year, so maybe you can take that as an example. But if you were starting something from scratch, is there some guidance or some thoughts on what it is that you would build first? And what is it that you would stay away from or avoid building to start with?
Suman:
Yeah, I would say if you're building a company, one thing I've learned over the past year is focus on the customer pain point first. Focus on a burning problem, pick a burning problem and solve that for the customer. And I think that's the key. As long as it's a burning problem, your product will have a lot of customer interest and a lot of customer pull. So not having a burning problem kind of makes that hard.
Jose:
Yeah, that's fair. And a question on you, if I may, and your company. How many agents do you now have working for you?
Suman:
I have quite a few agents running in the background as we speak. Seven to ten tabs running, all doing different things.
Jose:
All right. So you're here with us and the agent team is doing the work. That's very good. Hopefully they're not deleting any stuff in production. That's what I hope. Very good. So just wrapping up, just a couple of rapid-fire questions. And the first one would be, do you have any recommendation for the audience in terms of a book, a podcast, a thought leader that you think the audience should be consuming or listening to?
Suman:
Yeah. I mean, there are generic podcasts, but one of the things I've recently enjoyed is this podcast called Acquired. They actually talk about how large companies are built. And I think the stories about how these products came to be are fascinating, given that I'm building a product from scratch. A lot of the stories actually have a lot of emotional element to them and a business element to them. And it's kind of great to see how large companies are built. Having gone through that process, the podcast is amazing. The podcasters are very good storytellers. So it's a very engaging podcast, but also, more importantly, they deep dive into the business side of things and the emotional side of things, not just the market side of things. That's what I really love about that podcast.
Jose:
Yeah, awesome. Thank you for the suggestion. And final question. To you, Suman, scalability is?
Suman:
The ability to take on more with the same amount of reliability and performance.
Jose:
Very good. That's a great way to wrap it up. Thank you so much for your time. Really appreciate it.
Suman:
Likewise. I enjoyed being on here. Thank you.
Jose:
And that's it for this episode of the Smooth Scaling Podcast. Thank you so much for listening. If you enjoyed, consider subscribing and perhaps share it with a friend or colleague. If you want to share any thoughts or comments with us, send them to smoothscaling@queue-it.com. This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it, your virtual waiting room partner. I'm your host, José Quaresma. Until next time, keep it smooth, keep it scaled.
[This transcript is auto-generated]
Â