Designing Deep Learning APIs: Idempotency, Rate Limits, and Surviving Real-World Failures

[0:00]Yurii: Hello and welcome to the Deep Learning Stack podcast, where we dive into the real-world challenges and strategies of building production-grade machine learning systems. I’m your host, Max Tran. Today, we’re exploring what it really takes to design robust APIs and integrations for deep learning—especially focusing on idempotency, rate limits, and surviving those inevitable, messy failures. We’re joined by Dr. Lena Rajan, Principal ML Systems Architect at NeuralMesh Labs. Lena, it’s great to have you here.

[0:40]Dr. Lena Rajan: Thanks, Max. I’m excited to dig into this topic. It’s one of those areas that sounds dry on paper but is absolutely critical in practice, especially when your models are powering real products.

[1:10]Yurii: Absolutely. Before we get into the weeds, can you give listeners a quick sense of your background and what you focus on at NeuralMesh Labs?

[1:45]Dr. Lena Rajan: Sure. My background’s in distributed systems and machine learning. At NeuralMesh Labs, we help teams design and scale ML infrastructure, which means a lot of my time is spent making sure that APIs for inference and training are robust, observable, and actually work under pressure. And, as you can imagine, that’s where a lot of the gnarly integration challenges show up.

[2:20]Yurii: Perfect setup. So let’s start at the top. Why are deep learning APIs fundamentally different from, say, a classic REST API for a CRUD application?

[3:15]Dr. Lena Rajan: Great question. With deep learning APIs, you’re often dealing with non-deterministic outcomes, heavy compute, and sometimes stateful resources behind the scenes. Unlike a typical CRUD API—where a GET or POST is usually predictable—an inference endpoint might hit a GPU, load a model version, or trigger a workflow that can take seconds or even minutes. And that introduces a bunch of complexity, especially around idempotency and reliability.

[5:00]Yurii: So, even just retrying a request isn’t always safe or simple. We’re going to dig into that, but let’s define idempotency for folks who might be newer to the concept. How would you describe it in plain language?

[5:40]Dr. Lena Rajan: Idempotency means that if you send the same request multiple times—say, because of a network blip or a retry—you should get the same result, or at least not cause unintended side effects. For ML APIs, that sounds simple, but it gets tricky if your endpoint does things like enqueue jobs, charge credits, or update state.

[6:20]Yurii: Right, and in the deep learning world, the stakes for getting that wrong can be high. Can you walk us through a concrete example where idempotency made or broke a system?

[7:05]Dr. Lena Rajan: Absolutely. I remember one integration where the inference API would assign a unique ID to each prediction task, but the client sometimes retried requests without realizing the first one had already been processed. Because the backend didn’t enforce idempotency, this led to duplicate predictions, which then triggered duplicate billing and downstream confusion. It took weeks to track down.

[7:50]Yurii: Ouch. So, what would’ve helped there? Is it as simple as using idempotency keys, or are there deeper issues?

[8:20]Dr. Lena Rajan: Idempotency keys are a great start—think of them as unique tokens the client includes so the backend can recognize repeat requests. But you also need to design your backend logic to be aware of those keys and avoid double-processing. And in ML, you have to consider that even the model output might not be bit-for-bit identical each time, especially with stochastic models.

[9:10]Yurii: Let’s pause and define that—when you say stochastic models, you mean models that have some randomness in their predictions, right?

[9:25]Dr. Lena Rajan: Exactly. Some models, especially generative or sampling-based ones, can return slightly different results on each call, even with the same input. That’s another wrinkle for idempotency: if the client expects repeat calls to return the same answer, you might need to cache the first result and return it for subsequent requests with the same idempotency key.

[10:15]Yurii: So if you’re building an API for something like image generation, you have to decide whether repeat requests should truly be identical or just not duplicate side effects?

[10:40]Dr. Lena Rajan: Exactly. Sometimes the contract is 'no duplicate side effects,' like billing or data writes. Other times, especially for user-facing outputs, you need to make a product decision: do users expect the exact same output, or just the same status? Being explicit in your API docs is crucial here.

[11:15]Yurii: Let’s get into a real incident. Can you share a mini case study where lack of idempotency caused a headache in a deep learning pipeline?

[11:55]Dr. Lena Rajan: Sure. One team I worked with had a speech-to-text service. Their mobile app would sometimes lose connectivity and retry submissions. Because the backend didn’t deduplicate requests, the same audio clip got transcribed—and billed—multiple times. Users complained, and the team had to refund a lot of charges. The fix was to introduce idempotency tokens on the client and enforce deduplication on the server.

[13:00]Yurii: It’s wild how often these issues only show up at scale. Let’s talk about another subtle source of failures: race conditions. What does that look like in a distributed ML system?

[14:00]Dr. Lena Rajan: In distributed ML, you might have multiple workers picking up jobs from a queue. If your queue or API isn’t careful, two workers might process the same job due to timing quirks. That can lead to duplicated outputs, wasted compute, or even data corruption if results are merged badly.

[14:45]Yurii: How do you usually defend against that? Is it a matter of atomic operations, or are there higher-level patterns?

[15:10]Dr. Lena Rajan: Both. Atomic job claiming in the queue helps, but you also need idempotency at the API layer. And sometimes, you need to design your storage or output logic so that duplicate results are harmless—think of it as being intentionally redundant, just in case.

[16:00]Yurii: So, defensive coding—being paranoid in the right places. Let’s shift gears to rate limiting. Why is this especially important for deep learning APIs?

[18:30]Dr. Lena Rajan: Deep learning models are expensive to run, both in terms of compute and cost. If you don’t rate limit, a misbehaving client or a traffic spike can easily overload your GPUs, leading to latency spikes or even crashing your inference service. Plus, you want to make sure no single user can hog all the resources.

[19:00]Yurii: What are some strategies for implementing rate limits? Are there patterns you recommend for ML endpoints specifically?

[20:15]Dr. Lena Rajan: The classic ones are token bucket and leaky bucket. For ML APIs, I like to set limits at multiple levels—per user, per API key, and sometimes even per endpoint. That way, if someone’s spamming one part of your API, it doesn’t take down the whole system.

[21:00]Yurii: Can you walk us through a time when missing or poorly tuned rate limits caused real trouble?

[21:35]Dr. Lena Rajan: Definitely. One project had a sudden spike in requests from a new integration partner. The API didn’t have per-client rate limits, so their traffic overwhelmed the inference cluster. Latency shot up for everyone, and the whole service was degraded until we put emergency limits in place. Lesson learned: always rate limit, and always monitor.

[23:00]Yurii: That’s a great segue to monitoring. But before we get there, what’s your take on balancing user experience and protecting your models? Isn’t there a risk that strict rate limits frustrate legitimate users?

[23:35]Dr. Lena Rajan: Absolutely, there’s a trade-off. Too strict, and you block real users; too loose, and you risk outages. I like to provide clear headers—X-RateLimit-Remaining, for example—and offer burst capacity with gradual backoff. Also, premium users might get higher limits. Transparency is huge to keep users happy.

[24:20]Yurii: Let’s touch on a second mini case study. Can you share an example where aggressive retries or spikes led to cascading failures?

[24:40]Dr. Lena Rajan: Sure. There was a visual search API where clients, on hitting a 429 Too Many Requests error, would immediately retry in a tight loop. Instead of backing off, that just hammered the system harder, making recovery impossible. We had to re-educate clients and implement exponential backoff on both sides.

[25:30]Yurii: So, exponential backoff—waiting longer between retries—helps the system recover?

[25:50]Dr. Lena Rajan: Exactly. It gives your backend a chance to breathe and actually serve requests instead of being stuck in a retry storm. Sometimes we also implement circuit breakers to temporarily shed load.

[26:15]Yurii: For listeners unfamiliar, a circuit breaker is like a fuse that cuts off requests to a failing service temporarily, right?

[26:30]Dr. Lena Rajan: That’s right. It’s a pattern from distributed systems where, if the error rate crosses a threshold, you stop sending requests for a bit and let things recover. It’s a lifesaver in high-traffic ML APIs.

[27:10]Yurii: Let’s recap where we are. We’ve talked about idempotency, race conditions, and rate limiting as pillars of robust ML API design. Before we head into observability and error handling, anything you want to add on these fundamentals?

[27:30]Dr. Lena Rajan: Just that these issues almost never show up in the happy path. You really only see them under real-world stress, when multiple systems are interacting, and when something unexpected happens. So it pays to be a little pessimistic and design for chaos from day one.

[27:30]Yurii: Alright, welcome back! We’ve covered a lot of the basics around API design for deep learning integrations. Let’s shift gears a bit and dive into some real-world challenges, especially when things don’t quite go as planned.

[27:40]Dr. Lena Rajan: Yeah, because honestly, it’s in those failure cases that you really learn what your API is made of.

[27:48]Yurii: Absolutely. Maybe we can start with a story? Do you have an example where things went sideways in production?

[28:10]Dr. Lena Rajan: Sure. There was this project where a client wanted to integrate a deep-learning-powered image analysis tool into their workflow. The API was designed to be synchronous, expecting instant results. But once it hit production load, inference latency spiked—sometimes taking 30, 40 seconds. Suddenly, clients were hammering retry, assuming something was wrong, but it was just slow processing.

[28:25]Yurii: Oof. So what happened—did it cause duplication?

[28:35]Dr. Lena Rajan: Exactly. Since idempotency wasn’t enforced, every retry triggered a new inference job, blowing up compute costs and flooding the queue. The system basically started eating itself.

[28:47]Yurii: That’s a classic. So, if you’re listening, this is why idempotency isn’t just a checkbox. It’s essential, especially with expensive compute.

[29:02]Dr. Lena Rajan: Absolutely. And the fix was to introduce idempotency keys—clients would generate a unique key per request, and the API would store the result for that key. That way, retries didn’t create new jobs, just returned the cached outcome.

[29:14]Yurii: It’s such a simple thing, but so easy to overlook. Let’s talk about rate limits. How do you set good limits for deep learning APIs?

[29:29]Dr. Lena Rajan: The right answer depends a lot on your backend capacity and user profiles. For deep learning, rate limits aren’t just about fair usage—they’re about protecting your infrastructure. If five clients spike traffic at once, your GPU cluster might overload.

[29:37]Yurii: So, what’s your approach? Fixed per-client limits or something dynamic?

[29:52]Dr. Lena Rajan: I usually recommend a hybrid. Start with conservative per-client limits, but monitor usage. If a client consistently stays within limits, you can grant higher throughput. Some teams use token buckets or leaky bucket algorithms to smooth out bursts.

[30:01]Yurii: And what about communicating those limits? Any tips?

[30:13]Dr. Lena Rajan: Transparency is key. Return clear headers—like X-RateLimit-Remaining. And document your policies. I’ve seen devs spend hours debugging 429 errors without realizing there was a cap.

[30:27]Yurii: Let’s do a quick case study. I remember a fintech company integrating fraud detection via a deep learning API. They kept getting sudden spikes in false positives. What’s your take on what could have gone wrong?

[30:46]Dr. Lena Rajan: I’ve seen this. Sometimes, deep learning models drift if they’re not retrained or monitored. But in one case, it turned out the integration was sending duplicate transaction calls due to a flaky upstream system. The API was stateless, so it made separate predictions for the same event, amplifying noise.

[30:55]Yurii: So, would idempotency have helped here too?

[31:07]Dr. Lena Rajan: Yes, plus better event deduplication upstream. But also, the API could have provided more context in its responses—like a unique prediction ID—so clients could correlate results.

[31:16]Yurii: That’s a great tip. Let’s talk about timeouts. How do you handle long-running inferences?

[31:30]Dr. Lena Rajan: For anything that’s not truly real-time, I prefer asynchronous APIs. The client submits a job, gets a job ID, and polls or receives a webhook when it’s done. That way, you avoid HTTP timeouts and give yourself flexibility to scale.

[31:38]Yurii: What are the trade-offs with async APIs?

[31:51]Dr. Lena Rajan: Async is more complex for clients—they need to manage state. But for deep learning, it’s often the only way to handle unpredictable inference times and still be robust. You can also implement retries and partial failure recovery more gracefully.

[32:01]Yurii: Let’s switch it up. Can you share another mini-case study—maybe something from healthcare?

[32:18]Dr. Lena Rajan: Sure. A hospital was integrating a medical imaging model via API. During a major rollout, they hit a wall: images would intermittently fail to process, with vague error codes. After digging, we found their API gateway had a strict payload size cap, but large MRI images were exceeding it.

[32:27]Yurii: Wow, so the integration failed silently?

[32:40]Dr. Lena Rajan: Exactly. The error handling was generic, so it looked like a server bug. The fix was to implement explicit size validation and return clear errors, so clients could downscale images or chunk uploads.

[32:47]Yurii: It’s amazing how much difference good error messages make.

[32:56]Dr. Lena Rajan: Totally. And with deep learning, data format errors are especially common—if you’re not strict on validation, you’ll get bizarre failures downstream.

[33:05]Yurii: Let’s do a rapid-fire round. I’ll ask some quick questions, just say the first thing that comes to mind. Ready?

[33:07]Dr. Lena Rajan: Let’s do it.

[33:10]Yurii: Best status code for a successful async job submission?

[33:12]Dr. Lena Rajan: 202 Accepted.

[33:16]Yurii: Worst mistake teams make with API docs?

[33:19]Dr. Lena Rajan: Forgetting to document edge cases and error codes.

[33:24]Yurii: Idempotency—header, request param, or body field?

[33:27]Dr. Lena Rajan: Header is best—less risk of accidental collision.

[33:31]Yurii: Most overlooked security risk?

[33:34]Dr. Lena Rajan: Exposing raw model outputs without sanitization.

[33:38]Yurii: Favorite API error message format?

[33:41]Dr. Lena Rajan: JSON with code, message, and trace ID.

[33:45]Yurii: Best way to test rate limit enforcement?

[33:49]Dr. Lena Rajan: Automated scripts simulating bursts plus slow drips.

[33:53]Yurii: Last one—sync or async for most deep learning APIs?

[33:57]Dr. Lena Rajan: Async, unless you’re sure response times are snappy.

[34:02]Yurii: Nice. Let’s unpack security a bit more. What’s unique about securing APIs around deep learning?

[34:18]Dr. Lena Rajan: Two things: model inversion attacks—where attackers try to reconstruct training data from outputs—and prompt injection or adversarial inputs. You need input validation and output filtering, plus all the usual API security: auth, rate limits, logging.

[34:25]Yurii: So, don’t just think about API keys and HTTPS.

[34:32]Dr. Lena Rajan: Exactly. And monitor for unusual usage patterns—deep learning APIs are expensive, and abuse can rack up real costs.

[34:38]Yurii: Let’s touch on monitoring. What metrics matter most for deep learning integrations?

[34:54]Dr. Lena Rajan: Latency, error rates, GPU utilization, and queue depths. But also, model-level metrics—like input distribution drift and output confidence scores. Sometimes, a sudden spike in low-confidence predictions is your first sign of a production issue.

[35:03]Yurii: What’s your favorite way to handle schema changes in APIs?

[35:16]Dr. Lena Rajan: Versioning. Never break old clients. Deprecate slowly, support multiple versions, and communicate changes early. For deep learning, even a small input shift can break whole workflows.

[35:23]Yurii: Let’s talk about observability. Any tools or techniques you swear by?

[35:33]Dr. Lena Rajan: Structured logging with trace IDs, so you can follow a request from API to model and back. Also, real-time dashboards for queue status and hardware health.

[35:39]Yurii: And for alerting—do you set strict thresholds or more adaptive ones?

[35:50]Dr. Lena Rajan: Start strict, then tune. You want to catch genuine incidents but avoid alert fatigue. I like to page only when a metric stays abnormal for more than a few minutes.

[35:57]Yurii: Let’s revisit error handling. What’s the best way to share model-specific errors with API clients?

[36:11]Dr. Lena Rajan: Standardize your error schema, but include a ‘details’ field for model quirks. For example: ‘Invalid image format, expected PNG or JPEG.’ Don’t leak internal stack traces, but be actionable.

[36:20]Yurii: Any advice for teams building their first deep-learning-powered API?

[36:34]Dr. Lena Rajan: Start simple! Support a few key use cases, nail down idempotency and basic rate limits, and only add complexity when you see real usage patterns. Don’t try to anticipate every edge case up front.

[36:43]Yurii: Let’s do one last mini-case study—maybe from e-commerce?

[37:06]Dr. Lena Rajan: Sure. An online retailer built a recommendation engine using deep learning. Their API was super fast in staging, but under live traffic, inference times ballooned. Turned out they hadn’t tested with real data volumes—images were much larger, and user requests clustered during sales. Eventually, the system started refusing requests with 500 errors.

[37:11]Yurii: So, what would you do differently?

[37:25]Dr. Lena Rajan: Load test with production-sized data, set up backpressure in the API to queue requests gracefully, and implement clear error handling. Also, monitor for slowdowns and scale GPU resources ahead of big events.

[37:36]Yurii: Great advice. We’re getting into the home stretch. Maybe let’s talk about how to actually implement some of these best practices—like an implementation checklist.

[37:43]Dr. Lena Rajan: Perfect. I’ll run through a checklist I use with teams launching deep learning APIs.

[37:45]Yurii: Let’s hear it!

[37:52]Dr. Lena Rajan: Alright, step one: Define your input and output schemas clearly. Be strict on validation—reject anything ambiguous.

[37:55]Yurii: Got it—no vague data allowed.

[38:03]Dr. Lena Rajan: Step two: Implement idempotency. Use a unique key per request and cache results, especially for expensive operations.

[38:06]Yurii: Idempotency, check.

[38:13]Dr. Lena Rajan: Step three: Set and document rate limits. Use headers to inform clients, and monitor for abuse.

[38:16]Yurii: So everyone knows what to expect.

[38:26]Dr. Lena Rajan: Step four: Choose synchronous or asynchronous API styles based on expected latency. For anything that might take more than a few seconds, go async.

[38:30]Yurii: Don’t force everything through sync just because it’s easier!

[38:39]Dr. Lena Rajan: Exactly. Step five: Standardize error responses. Use codes, messages, and trace IDs. Make errors actionable.

[38:41]Yurii: So clients can debug quickly.

[38:50]Dr. Lena Rajan: Step six: Monitor production metrics—latency, error rates, usage patterns, and model-specific stats like confidence or drift.

[38:54]Yurii: Don’t wait for users to tell you something’s wrong.

[39:02]Dr. Lena Rajan: Exactly. Step seven: Secure your endpoints—auth, input validation, and watch for abuse or adversarial inputs.

[39:05]Yurii: Security isn’t optional.

[39:14]Dr. Lena Rajan: And finally, step eight: Document everything. Especially edge cases, versioning, and error codes. Good docs save everyone’s time.

[39:23]Yurii: That’s a fantastic checklist. Maybe we can summarize the biggest ‘gotchas’—the mistakes you see teams make again and again?

[39:41]Dr. Lena Rajan: Sure. Number one: skipping idempotency, leading to resource drains. Two: underestimating real-world data sizes and request patterns. Three: not monitoring models for drift or weird outputs. Four: vague error handling. And five: poor documentation.

[39:47]Yurii: Do you see teams ever over-engineer things?

[40:01]Dr. Lena Rajan: Definitely. Sometimes teams try to anticipate every possible edge case up front, which adds complexity. It’s better to start with a solid foundation and iterate as you see how users actually behave.

[40:08]Yurii: How about testing—what does good testing look like for these APIs?

[40:24]Dr. Lena Rajan: You need unit tests for schema validation, integration tests for end-to-end flows, and load tests with real or representative data. Also, test for error scenarios—timeouts, malformed payloads, rate limiting.

[40:31]Yurii: And for model updates? How do you avoid breaking clients?

[40:44]Dr. Lena Rajan: Always test new models behind feature flags or with a subset of traffic first. Monitor outputs for regressions before a full rollout. And communicate upcoming changes to your API consumers.

[40:51]Yurii: Let’s talk about scaling. Any tips for preparing for unexpected spikes?

[41:08]Dr. Lena Rajan: Pre-warm your inference servers, use auto-scaling if possible, and implement queuing with clear backpressure signals to clients. And always have a plan for graceful degradation—like returning ‘try again later’ instead of 500s.

[41:15]Yurii: How do you handle versioning when the model itself changes, not just the API?

[41:28]Dr. Lena Rajan: Expose the model version in the API response. That way, clients can audit results or reproduce behaviors. If models are radically different, consider a new API version or a ‘model_version’ parameter.

[41:36]Yurii: Let’s go a bit deeper on monitoring for model drift—what’s your process?

[41:51]Dr. Lena Rajan: Track input data distributions and output confidence over time. Set up alerts for unusual patterns. And periodically review a sample of predictions, especially if your use case is high-stakes—like healthcare or finance.

[41:58]Yurii: Do you ever surface model confidence scores in the API response?

[42:12]Dr. Lena Rajan: Yes, but with caveats. Confidence scores can help clients make better decisions, but they can also be misinterpreted. Document what the score means, and explain its limitations.

[42:20]Yurii: How do you recommend handling partial failures—like when a batch request partly succeeds?

[42:34]Dr. Lena Rajan: Return detailed results per item, with clear status for each. Don’t fail the whole batch if one item errors. And provide enough info for clients to retry only the failures.

[42:41]Yurii: Great. Let’s talk about cost management, since GPU time isn’t cheap.

[42:54]Dr. Lena Rajan: Track usage by client, set quotas, and alert if someone is about to exceed their allocation. Also, consider tiered pricing or throttling for non-critical workloads.

[43:01]Yurii: Any thoughts on exposing batch endpoints for efficiency?

[43:13]Dr. Lena Rajan: Batch endpoints are fantastic for throughput, but require good error reporting. Also, be clear about batch size limits—huge batches can overwhelm memory or delay results for everyone.

[43:20]Yurii: How do you handle backward compatibility when adding new features?

[43:33]Dr. Lena Rajan: Default to optional parameters, and never change the meaning of existing fields. If a new feature could break old clients, gate it behind a version or flag.

[43:40]Yurii: What’s your process for deprecating old API versions?

[43:54]Dr. Lena Rajan: Announce early, support both versions for a transition period, and provide migration guides. Monitor usage and reach out to high-traffic clients directly.

[44:02]Yurii: Let’s discuss documentation. What’s the bare minimum that must be in your API docs?

[44:18]Dr. Lena Rajan: Request/response examples, clear error codes, input/output schema, rate limits, authentication steps, and versioning details. Also, real examples—don’t just auto-generate everything.

[44:26]Yurii: If you could give one piece of advice to someone launching their first deep-learning API, what would it be?

[44:38]Dr. Lena Rajan: Launch with the smallest viable feature set, instrument everything, and be ready to iterate. Real-world usage will surprise you.

[44:45]Yurii: Let’s do a quick recap of our implementation checklist, just to make it concrete for listeners.

[44:59]Dr. Lena Rajan: Absolutely. Here’s the short version: strict schema validation, idempotency, rate limits, async for long-running tasks, standardized errors, production monitoring, robust security, and thorough documentation.

[45:08]Yurii: Perfect. As we wrap up, any last words of warning or encouragement for teams taking their deep learning APIs to production?

[45:23]Dr. Lena Rajan: Expect surprises—especially in production. Build with failure in mind, listen to your users, and don’t be afraid to iterate. And remember, the boring stuff—like error handling and docs—matters just as much as the fancy models.

[45:34]Yurii: That’s a great note to end on. Before we sign off, let’s run through a quick final checklist for our listeners—what should they double-check before launch?

[45:59]Dr. Lena Rajan: Sure. 1: Are your schemas validated and documented? 2: Is idempotency implemented for critical endpoints? 3: Are your rate limits enforced and visible to clients? 4: Do you have clear error responses? 5: Is monitoring in place for latency, usage, and drift? 6: Are all endpoints secured? 7: Is your documentation live and up to date?

[46:04]Yurii: If you can check all those boxes, you’re in good shape.

[46:09]Dr. Lena Rajan: And don’t forget to have a rollback plan if something goes wrong!

[46:15]Yurii: That’s huge. Alright, thank you so much for sharing your experience and insights today.

[46:19]Dr. Lena Rajan: Thanks for having me—always a pleasure.

[46:29]Yurii: To everyone listening, we hope this gives you a clearer path to building robust, production-ready deep learning APIs and integrations. For more resources, check the show notes.

[46:36]Dr. Lena Rajan: And if you run into weird failures, remember—you’re not alone. We’ve all been there.

[46:44]Yurii: Thanks for tuning in to Softaims. Don’t forget to subscribe, leave us a review, and let us know what topics you want us to cover next.

[46:48]Dr. Lena Rajan: Take care, and happy building!

[46:52]Yurii: See you next time.

[54:15]Yurii: And that brings us to the end of today’s episode on designing APIs and integrations around deep learning—idempotency, rate limits, and what happens when things go wrong. If you want to dive deeper, check out our curated links and guides in the episode description.

[54:28]Dr. Lena Rajan: We’ll be back soon with more discussions on machine learning in production. Until then, keep learning and keep shipping!

[55:00]Yurii: This is Softaims, signing off. Have a great day!