Building Robust Data Science APIs: Idempotency, Rate Limits, and Failure Modes

[0:00]Alam: Welcome back to the Data Science Stack podcast, where we get practical about building and scaling real-world systems. I’m your host, Alex Lin. Today, we’re unpacking a topic that every data scientist and engineer will face at some point: how do you design APIs and integrations that actually survive the messy realities of production? We’re talking idempotency, rate limits, and what happens when things fail in the wild.

[1:20]Alam: To help us dig deep, I’m thrilled to welcome Dr. Nina Park, Lead Data Science Platform Engineer at Axion Analytics. Nina, thanks for joining us!

[1:32]Dr. Nina Park: Thanks, Alex. I’m really excited to be here. This is a topic close to my heart because I’ve seen even the most elegant models trip over these issues when it’s time to ship them.

[1:45]Alam: Fantastic. Before we dive into the technical weeds, can you share a bit about your background and what you do at Axion Analytics?

[2:02]Dr. Nina Park: Sure. My role is a mix of enabling data science at scale and building the platforms that make those models usable by the rest of the business. That means a lot of time spent on APIs, orchestration, and making sure our integrations don’t fall over when real users or upstream systems hit them.

[2:45]Alam: Awesome. So let’s set the stage. Why are APIs such a big deal in data science projects nowadays?

[3:10]Dr. Nina Park: Great question. APIs are really the glue between data science and the rest of the business. Whether you’re serving predictions, moving data between systems, or triggering workflows, APIs let teams interact with models without needing to know their internals. And as companies connect more systems, those APIs become mission-critical.

[3:38]Alam: That’s a great way to put it. And yet, so many teams don’t realize how quickly things can go wrong with a simple integration.

[4:03]Dr. Nina Park: Exactly. I’ve seen it happen over and over. It’s not just about the math or the model—it’s about reliability, and that’s where things like idempotency and rate limiting come in.

[4:15]Alam: Let’s pause and define that first term. For folks who haven’t lived through these issues, what is idempotency in the context of APIs?

[4:37]Dr. Nina Park: In plain language, idempotency means that if you send the same request to an API multiple times—intentionally or by accident—you get the exact same result each time, and no unintended side effects. So, if your client retries or there’s a glitch, you don’t end up with duplicate records or extra charges.

[5:10]Alam: So it’s like pressing the elevator button twice—no matter how many times you press, it only goes to the floor once.

[5:22]Dr. Nina Park: Exactly! And in data science, this matters a lot when you’re doing things like batch scoring or updating records. If an API isn’t idempotent, it’s easy to introduce subtle data issues that are hard to unwind later.

[6:00]Alam: Can you share an example where lack of idempotency caused real pain?

[6:16]Dr. Nina Park: Absolutely. We had a pipeline where predictions were sent to an external system via API. Due to a network blip, the client retried the request, but the endpoint wasn’t idempotent—so the downstream system recorded the same prediction multiple times. Later, analysts were confused by the inflated counts. It took days to untangle.

[7:05]Alam: Ouch. And I bet those duplicate predictions had knock-on effects?

[7:12]Dr. Nina Park: They did. It threw off reporting, triggered duplicate notifications, and even caused a billing error downstream. All because the API didn’t enforce idempotency.

[8:10]Alam: So where do duplicate requests usually come from? Is it just network retries?

[8:25]Dr. Nina Park: That’s a big one, but not the only source. You might see retries from load balancers, user double-clicks, or even bugs in upstream schedulers. And with distributed pipelines, sometimes the same job gets replayed after a partial failure.

[9:00]Alam: Let’s get practical. How do you design APIs to be idempotent? What are the mechanics?

[9:16]Dr. Nina Park: A common pattern is to require an idempotency key—a unique token provided by the client for each logical operation. The server stores the result of that operation, and if it sees the same key again, it just returns the original response instead of doing the work again.

[10:00]Alam: Sounds simple. Where do teams trip up with idempotency keys?

[10:20]Dr. Nina Park: A few places. Sometimes clients forget to generate a unique key and just use the same one for everything, which defeats the purpose. Other times, the server doesn’t persist the results long enough, or the keys aren’t truly unique. And in complex workflows, it can be tricky to know what the idempotency boundary should be.

[12:00]Alam: Let’s bring in a mini case study. Can you share a story where idempotency keys saved the day—or didn’t?

[12:22]Dr. Nina Park: We had a model inference API that processed thousands of requests per minute. At one point, a batch job got stuck and started retrying the same requests over and over. Because each request had a proper idempotency key, the API just returned the cached results—no duplicate work, no double billing. If we hadn’t had that, it would have been a mess.

[13:15]Alam: That’s a great outcome. But have you ever seen it go wrong?

[13:26]Dr. Nina Park: Definitely. In another project, the team used timestamps as idempotency keys, but the clocks weren’t perfectly in sync across systems. That meant some retries were treated as new requests, leading to duplicate processing and subtle data drift.

[14:00]Alam: So time-based keys are risky. What’s your preferred method?

[14:18]Dr. Nina Park: I like using UUIDs or some hash of the logical operation. The main thing is that it’s unique per operation, not just per request. And, critically, the server has to store and check those keys for a reasonable window.

[14:45]Alam: Let’s talk about safe retries. How do you design for that, especially when the network is unreliable?

[15:07]Dr. Nina Park: You need two things: idempotency, so retries are safe, and a clear retry policy with exponential backoff. Exponential backoff means you wait longer between retries to avoid flooding the server. And you want to limit the total number of retries so you don’t hammer the system endlessly.

[16:10]Alam: Are there ever cases where retries themselves cause issues?

[16:22]Dr. Nina Park: Yes. If your retry logic is too aggressive, you can turn a minor network blip into a denial-of-service event—everyone’s client retries at once and overwhelms the server. That’s why rate limiting is such a critical complement to idempotency.

[17:00]Alam: Let’s define rate limiting for listeners. What is it, and why do we need it?

[17:22]Dr. Nina Park: Rate limiting is a way for an API to control how many requests a client can make in a given period. It protects the server from overload and enforces fairness between users. Without it, a runaway client or a bug could take down the whole service.

[18:30]Alam: What are some common patterns for rate limiting?

[18:52]Dr. Nina Park: The most common are fixed window, sliding window, and token bucket. Fixed window means you get a certain number of requests per minute or hour. Sliding window smooths that out. Token bucket lets you build up some burst capacity but still limits the overall rate. Each has trade-offs in terms of fairness and predictability.

[19:40]Alam: How do you decide which one to use for a data science API?

[19:59]Dr. Nina Park: It depends on your users. For batch jobs, token bucket is nice because it allows bursts but protects the backend. For user-facing APIs, sliding window tends to be fairer. And you might want different limits for different clients.

[20:30]Alam: Let’s bring this home. How do rate limits affect machine learning workflows?

[20:48]Dr. Nina Park: Batch jobs are a big one. You might have hundreds of thousands of predictions to score in a short window. If you hit the rate limit, jobs fail or slow down. That can cascade into missed SLAs or stale outputs. So, it’s crucial to communicate those limits to clients and design the pipeline for graceful degradation.

[22:00]Alam: Have you seen a scenario where rate limiting caused bigger problems than it solved?

[22:22]Dr. Nina Park: Yes, actually. In one project, the API team set strict per-minute limits without consulting the batch processing team. When the nightly scoring job ran, it hit the limit and started failing requests, but the client didn’t back off intelligently. That led to partial results and, worse, silent data loss.

[23:15]Alam: So, communication between teams is key. How did you resolve that?

[23:32]Dr. Nina Park: We ended up adding a special client type for scheduled jobs with a higher rate limit, and improved the client to queue and retry failed batches instead of dropping them. We also added better metrics so we could spot the problem next time.

[24:15]Alam: That’s a great segue to partial failures. What do you mean by that?

[24:37]Dr. Nina Park: Partial failures happen when some requests in a batch succeed and others fail. For example, in a thousand-record upload, nine hundred go through, but a hundred fail due to rate limits or network errors. If you’re not careful, you end up with inconsistent data states.

[25:00]Alam: How do you avoid those inconsistencies?

[25:15]Dr. Nina Park: Ideally, make batch operations transactional, so either everything succeeds or nothing does. If that’s not possible, track which items succeeded and which failed, and have a robust retry-and-reconciliation process. Logging and traceability are key.

[25:45]Alam: You mentioned retry strategies earlier. Some folks argue for aggressive retries, others for being more conservative. Where do you land on that spectrum?

[26:05]Dr. Nina Park: Honestly, it depends on the criticality of the operation and the expected failure mode. For non-critical, idempotent actions, aggressive retries with exponential backoff are fine. For operations with side effects or high cost, I prefer more conservative retry logic, maybe even alerting a human if it fails repeatedly.

[26:45]Alam: I’m going to push back a little. Sometimes, if you’re too conservative, you end up with persistent gaps in data, especially in large-scale pipelines. Isn’t it better to err on the side of retrying too much?

[27:05]Dr. Nina Park: That’s a fair point. If you can guarantee idempotency and your downstream systems are resilient, aggressive retries may be safer than missing data. The key is to monitor and have guardrails so you don’t accidentally cause more harm.

[27:30]Alam: So, balance, observability, and knowing your failure modes. That’s a perfect place to pause. When we come back, we’ll talk about how to monitor these APIs, evolve them safely, and share more stories from the trenches. Stay with us.

[27:30]Alam: Alright, so we’ve covered the basics and some of the early pitfalls, but I want to turn the conversation a bit. Let’s talk about what happens when APIs and data science integrations start to scale—because that's where things get really interesting.

[27:38]Dr. Nina Park: Absolutely. The reality is, most of the real headaches show up not in the prototype, but once you hit production. Rate limits, idempotency, and what I like to call 'failure choreography' become front and center.

[27:47]Alam: Failure choreography—I love that phrase. Can you give an example of what you mean?

[27:55]Dr. Nina Park: Sure. Imagine a data science team consuming a third-party enrichment API. Things are fine in testing, but once they go live, their batch jobs start hitting rate limits, retries get out of sync, and suddenly you’re processing duplicate records or, worse, dropping data entirely.

[28:10]Alam: So you’re seeing, say, a job that was supposed to process 10,000 records, but only 8,000 make it through because of silent failures or aggressive rate limiting?

[28:19]Dr. Nina Park: Exactly. Or you see 12,000 because retries weren't idempotent and created duplicates. It’s chaos if you’re not careful about your design.

[28:27]Alam: Let’s dig into that. What’s the best way to design for idempotency in these kinds of data workflows?

[28:35]Dr. Nina Park: Idempotency is about ensuring that repeating the same operation doesn’t change the outcome after the first success. For APIs, that means using idempotency keys—unique identifiers for each logical operation. The trick in data science pipelines is to propagate that key all the way from your source system through each transformation and API call.

[28:49]Alam: So, for example, if I’m sending a batch of user updates to a recommendation engine, I should generate and attach a unique key for each batch?

[28:59]Dr. Nina Park: Yes, and ideally a key per logical operation within the batch, if possible. Otherwise, if the batch fails halfway and you retry, you risk partial duplication or missed updates.

[29:07]Alam: What’s a common mistake you’ve seen teams make here?

[29:13]Dr. Nina Park: A big one is assuming the downstream API is idempotent by default. Plenty of APIs claim to be, but unless you test failure scenarios—like mid-request timeouts or partial processing—you might be surprised. Another is not persisting the idempotency keys, so you lose track in the event of a crash or redeploy.

[29:28]Alam: That’s a great point. Let’s do a quick mini case study. Can you walk us through a real-world scenario where ignoring idempotency caused headaches?

[29:37]Dr. Nina Park: Absolutely. I worked with a fintech team integrating with a third-party transaction scoring API. During a spike in traffic, they experienced intermittent 502 errors. Their retry logic simply resent the same transaction, but without an idempotency key. The provider scored and recorded some transactions twice, and the downstream ledger had to be manually reconciled later. It took weeks to untangle.

[29:57]Alam: That sounds painful. What was the fix?

[30:02]Dr. Nina Park: They added a unique transaction ID as an idempotency key to every call, and had a reconciliation step in their pipeline to catch any accidental duplicates. It took some refactoring, but it paid off quickly.

[30:13]Alam: Let’s shift gears for a second—rate limiting. We all know it’s necessary, but it can really throw off a data science job. What’s the best way to approach it?

[30:21]Dr. Nina Park: First, always check if the API provides clear rate limit headers in their responses. That’s your early warning system. Second, implement an adaptive backoff strategy—so if you’re getting close to the limit, your code should slow down, queue, or pause until the window resets.

[30:33]Alam: So, rather than just blasting requests and hoping for the best, you’re actually reading those headers and adjusting in real time?

[30:40]Dr. Nina Park: Exactly. And for batch jobs, consider chunking your data so that if you do hit a rate limit, you only have to retry a small subset, not the entire job.

[30:49]Alam: What about when APIs don’t provide those headers? Is there a workaround?

[30:54]Dr. Nina Park: You can estimate—keep track of your own request counts and timestamps. But it’s less reliable, especially if the provider changes their limits or applies them per account or per endpoint. When in doubt, ask for clarification, and, if possible, build relationships with the provider’s support team.

[31:08]Alam: Let’s do another quick case study. Can you share a story about rate limiting gone wrong?

[31:14]Dr. Nina Park: Sure. There was a retail analytics team that pulled inventory data from a supplier API. They didn’t realize the API had a rolling window rate limit. On Black Friday, their hourly batch job triggered the limit and got blocked for hours. Their dashboards showed stale data during the busiest sales period of the year.

[31:33]Alam: Ouch. How did they recover?

[31:37]Dr. Nina Park: They reworked their batch scheduler to spread requests more evenly throughout the hour, and added alerting to catch early warning signs of rate limiting. It wasn’t perfect, but it prevented a repeat.

[31:46]Alam: That’s such a practical lesson. Now, I want to touch on error handling, because it ties all of this together. What’s the right approach in a data science context?

[31:53]Dr. Nina Park: Resilience is key. You want to distinguish between transient failures—like a timeout or a 429 rate limit—and permanent ones, like a validation error. For transients, use retries with backoff. For permanents, log and alert, but don’t keep retrying forever.

[32:06]Alam: Is there a danger in being too aggressive with retries?

[32:12]Dr. Nina Park: Definitely. You can create an accidental denial-of-service attack on the API, or overwhelm your own systems. Always implement exponential backoff, and cap the number of retries.

[32:21]Alam: Let’s do a quick rapid-fire segment. I’ll throw out some scenarios or best practices, and you give your gut response. Sound good?

[32:24]Dr. Nina Park: Let’s do it!

[32:26]Alam: First one: Should you always log the full API request and response body?

[32:30]Dr. Nina Park: Log enough for debugging, but redact sensitive data. Privacy matters.

[32:33]Alam: Retry on all non-200 responses?

[32:36]Dr. Nina Park: No—only transient errors. For example, retry on 503, not on 400.

[32:40]Alam: Batch size: bigger batches or smaller chunks?

[32:43]Dr. Nina Park: Smaller chunks. Easier error recovery and less risk of hitting limits.

[32:46]Alam: Synchronous or asynchronous API calls for data pipelines?

[32:50]Dr. Nina Park: Asynchronous if possible—lets you decouple failures and scale better.

[32:53]Alam: How often do you test your error handling code?

[32:56]Dr. Nina Park: Every deployment. Simulate failures, don’t just hope for the best.

[32:59]Alam: Do you ever trust an API’s documentation completely?

[33:02]Dr. Nina Park: Never. Test everything, especially edge cases.

[33:05]Alam: Last one: Should you build in circuit breakers for third-party APIs?

[33:08]Dr. Nina Park: Absolutely. It’s a must for production reliability.

[33:12]Alam: Love it. Okay, let’s get a bit deeper into monitoring and observability. What are the most important metrics to track with these integrations?

[33:19]Dr. Nina Park: Request success and failure rates are obvious, but also track latency, retry counts, and deduplication events. If you see spikes in retries or duplicates, something’s probably wrong upstream.

[33:27]Alam: Do you recommend tracking payload sizes?

[33:31]Dr. Nina Park: Yes. Large payloads can cause timeouts or hit memory limits, especially with data-heavy APIs. It’s a leading indicator for scaling issues.

[33:36]Alam: What about alerting? How do you avoid alert fatigue but still catch real issues?

[33:42]Dr. Nina Park: Aggregate alerts rather than firing on every single error. Set up thresholds—like if failure rates cross a certain percentage, then alert. And rotate which team members get which alerts to avoid burnout.

[33:50]Alam: I’d love to hear your thoughts on documentation for these integrations. How do you make sure future team members don’t repeat the same mistakes?

[33:56]Dr. Nina Park: Maintain living docs—keep them updated with real problems you’ve encountered and how you fixed them. Include example requests, common error codes, and gotchas around rate limits or idempotency.

[34:04]Alam: And do you include real failure postmortems in documentation?

[34:08]Dr. Nina Park: Definitely. Those are gold for onboarding new folks and for continuous improvement.

[34:11]Alam: Let’s circle back to testing. How do you simulate real-world failures before you ever hit production?

[34:18]Dr. Nina Park: Use mocks and stubs to simulate API timeouts, slow responses, and error codes. For critical paths, chaos engineering techniques—randomly inject failures to see how your system behaves.

[34:26]Alam: Do you ever use sandbox environments from providers?

[34:29]Dr. Nina Park: Whenever available. But remember, sandboxes don’t always have the same rate limits or edge-case behaviors. So combine that with your own simulations.

[34:35]Alam: Let’s talk trade-offs. Is there ever a situation where you’d skip idempotency or rate limiting logic for speed?

[34:41]Dr. Nina Park: Maybe in a throwaway prototype, but never in production. The cost of fixing duplicate or lost data later is almost always higher than building it right the first time.

[34:48]Alam: How do you balance building robust error handling with not overengineering?

[34:53]Dr. Nina Park: Start with the most likely failure modes: timeouts, rate limits, and data validation errors. Add more only as you see real issues. Don’t try to anticipate every possible scenario upfront.

[35:01]Alam: I’m curious—have you ever disagreed with a team about how much resiliency to build in?

[35:06]Dr. Nina Park: Absolutely. Product wants speed, engineering wants safety. The middle ground is to start simple, but instrument everything so you can see what needs to be hardened as usage grows.

[35:13]Alam: Makes sense. Is there a time when failures actually taught you more than success?

[35:18]Dr. Nina Park: Pretty much every time. One integration failed under load because we underestimated how slow a third-party API could get during peak hours. That forced us to add queuing and backpressure logic, which we then reused on other projects.

[35:28]Alam: Speaking of reusing lessons, let’s imagine you’re advising a new data science team about to integrate with third-party APIs. What’s your elevator pitch checklist for them?

[35:36]Dr. Nina Park: Great question. Here’s what I’d say: One, always use idempotency keys. Two, respect rate limits. Three, distinguish between retryable and non-retryable errors. Four, monitor everything. Five, keep your documentation honest and up-to-date. And six, never assume the API will behave exactly as documented.

[35:49]Alam: Let’s double-click on those. For idempotency keys—should you generate them at the client or the server level?

[35:54]Dr. Nina Park: Client side, ideally. The client knows the intent of the action and can ensure uniqueness across retries or restarts.

[35:59]Alam: For rate limits, what’s your favorite open-source tool or library to help manage them?

[36:04]Dr. Nina Park: For Python, I like 'ratelimit' and 'tenacity' for retries with backoff. For distributed systems, Redis with a Lua script is a classic pattern.

[36:10]Alam: Any thoughts on when to use message queues in these pipelines?

[36:14]Dr. Nina Park: Whenever the downstream system can’t keep up, or when you want to smooth out bursts in traffic. Queues let you decouple ingestion from processing, and handle retries more gracefully.

[36:21]Alam: How do you handle schema changes in the API responses over time?

[36:25]Dr. Nina Park: Version your data models, and always validate incoming data. If you can, set up contract tests that alert you if the provider changes something unexpectedly.

[36:31]Alam: Let’s do a quick detour—what’s the strangest real-world API failure you’ve run into?

[36:36]Dr. Nina Park: A weather data provider once returned HTTP 200 with an HTML page instead of JSON during maintenance. Our parser choked, and we spent hours debugging what looked like a data issue but was really a silent error page!

[36:46]Alam: That’s classic. Extra validation would’ve caught it?

[36:49]Dr. Nina Park: Exactly. Always check the content type and do a sanity check on the response structure.

[36:53]Alam: Let’s transition to security. What’s unique about securing data science APIs and integrations?

[36:59]Dr. Nina Park: Data science workloads often move sensitive or proprietary data. That means strict authentication—API keys, OAuth, whatever the provider supports—and always encrypt in transit. And don’t forget, limit scopes and permissions to just what’s needed.

[37:08]Alam: What about secrets management? Any best practices?

[37:13]Dr. Nina Park: Never hardcode secrets in code or config files. Use a secrets manager, and rotate credentials regularly. And audit access to the secrets themselves.

[37:20]Alam: Let's talk about third-party dependencies. How do you evaluate API providers for long-term reliability?

[37:25]Dr. Nina Park: Look for clear status pages, responsive support, and a track record of uptime. Check their changelogs and see how often they deprecate endpoints. And always have a plan B or fallback if their service degrades.

[37:34]Alam: Have you ever had to switch providers mid-project?

[37:38]Dr. Nina Park: Yes, and it’s never fun. Build your abstractions so you can swap out providers with minimal code changes. Adapters or interface layers help a lot.

[37:46]Alam: Let’s do a quick recap. If you had to summarize the most common production failures with data science APIs, what would they be?

[37:51]Dr. Nina Park: One, silent data loss due to unhandled rate limits. Two, duplicate processing from missing idempotency. Three, schema changes breaking downstream code. And four, poor error handling leading to cascading failures.

[37:59]Alam: Let’s move into our final implementation checklist. I’d love for you to walk us through, step by step, how you’d build a robust API integration for a data science pipeline.

[38:03]Dr. Nina Park: Definitely. Here’s my go-to checklist:

[38:07]Dr. Nina Park: First—define the contract. What data are you sending and receiving? What are the error codes and limits?

[38:12]Dr. Nina Park: Second—add idempotency keys to every logical operation. Persist them for traceability.

[38:16]Dr. Nina Park: Third—implement adaptive rate limiting and exponential backoff for retries.

[38:20]Dr. Nina Park: Fourth—validate responses and handle schema changes with version checks.

[38:23]Dr. Nina Park: Fifth—add monitoring for success rates, latency, retries, and duplicates.

[38:26]Dr. Nina Park: Sixth—document every edge case, and share real postmortems.

[38:30]Dr. Nina Park: Seventh—test failure modes in staging, not just happy paths.

[38:34]Alam: That’s a fantastic checklist. Anything you’d add for teams working in regulated industries?

[38:38]Dr. Nina Park: Audit everything—every API call, every data change. Keep logs for compliance, and regularly review access control and encryption standards.

[38:45]Alam: We’re coming up on time, but I want to squeeze in one last question. What’s your personal favorite API design pattern or anti-pattern you wish more teams knew about?

[38:51]Dr. Nina Park: Pattern: the 'outbox' pattern for reliable event delivery. Anti-pattern: tightly coupling your pipeline to a single API’s quirks. Always abstract and insulate your integrations as much as possible.

[38:59]Alam: Before we wrap, any final advice for listeners designing their own APIs or integrations around data science?

[39:02]Dr. Nina Park: Expect things to go wrong. Invest early in resilience, observability, and good habits like idempotency. Your future self—and your users—will thank you.

[39:08]Alam: This has been such a rich conversation. To close us out, let’s recap your implementation checklist one more time for our listeners.

[39:13]Dr. Nina Park: Absolutely. Here are the essentials:

[39:15]Dr. Nina Park: 1. Define your contract and expectations.

[39:18]Dr. Nina Park: 2. Always use idempotency keys and persist them.

[39:21]Dr. Nina Park: 3. Build in adaptive rate limiting and backoff.

[39:24]Dr. Nina Park: 4. Validate and version your data models.

[39:27]Dr. Nina Park: 5. Monitor, alert, and regularly review real failures.

[39:30]Dr. Nina Park: 6. Keep your docs alive and honest.

[39:33]Alam: Couldn’t have said it better myself. Thanks so much for sharing your expertise and stories with us today.

[39:36]Dr. Nina Park: Thanks for having me—this was a blast.

[39:39]Alam: And thanks to everyone listening. If you got value from today’s episode, share it with your team, subscribe, and let us know what topics you want to hear next time.

[39:45]Alam: You’ve been listening to Softaims. Until next time, keep building resilient, reliable data systems. Take care!

[39:48]Alam: And we are out. Thanks again!

[39:51]Alam: Stay tuned for more episodes on the Softaims data-science stack.

[39:54]Alam: See you soon.

[39:57]Alam: Goodbye!

[40:00]Dr. Nina Park: Goodbye!

[40:15]Alam: Thanks for listening to Softaims.

[40:30]Alam: If you enjoyed this conversation, consider rating and reviewing us wherever you get your podcasts.

[40:50]Alam: For show notes, resources, and more episodes, head to softaims.com/data-science.

[41:10]Alam: Take care, and happy building.

[41:20]Alam: That’s a wrap.

[41:35]Alam: We’ll see you next time on Softaims.

[41:50]Alam: Final word from our guest?

[41:55]Dr. Nina Park: Keep learning from failures—they’re your best teacher.

[42:00]Alam: Perfect note to end on. See you next episode.

[42:10]Alam: Thanks, everyone!

[42:30]Alam: Goodbye!

[42:35]Dr. Nina Park: Bye!

[55:00]Alam: Softaims out.