DEV Community: Dakshan Reddy M

🚀 What Happens When You Train 100 ML Models at Once?

Dakshan Reddy M — Tue, 04 Aug 2026 13:41:09 +0000

🚀 What Happens When You Train 100 ML Models at Once?

Most machine learning tutorials stop after training a single model.

model.fit(X_train, y_train)

But what happens when you need to train 100 models simultaneously?

That question completely changed how I thought about machine learning systems.

Instead of thinking like a data scientist, I had to start thinking like a backend engineer.

The Problem

Imagine you're experimenting with different models.

Random Forest
XGBoost
Logistic Regression
Neural Networks

Now multiply that by:

10 datasets
5 hyperparameter combinations
2 feature engineering approaches

Suddenly you're training 100+ experiments.

Running them one by one isn't practical.

The Traditional Workflow

Model 1
    ↓
Wait...

Model 2
    ↓
Wait...

Model 3
    ↓
Wait...

...

CPU utilization stays low.

Resources are wasted.

Development becomes slow.

The Better Approach

Instead of running one experiment at a time, I built a pipeline where every experiment becomes a job.

User

↓

FastAPI

↓

Redis Queue

↓

Worker 1
Worker 2
Worker 3
Worker 4

↓

Model Training

↓

Results

Now multiple experiments can run in parallel.

Why Use a Queue?

Without a queue:

Request

↓

Train Model

↓

Wait 10 Minutes

The API blocks until training finishes.

That's a terrible user experience.

With a queue:

Request

↓

Redis Queue

↓

Return Job ID

↓

Background Worker

↓

Training

↓

Completed

The API responds almost instantly.

Why Multiple Workers?

Imagine each worker as another engineer helping with experiments.

Worker 1 → Model A

Worker 2 → Model B

Worker 3 → Model C

Worker 4 → Model D

Instead of waiting for one experiment to finish, several run simultaneously.

Docker Made Everything Easier

Packaging every service inside Docker meant each worker had:

The same dependencies
The same Python version
The same libraries

No more:

"It works on my machine."

Monitoring Progress

Every experiment gets a unique Job ID.

Instead of wondering whether training has finished, the client can simply check:

GET /jobs/{id}

Possible responses:

Pending
Running
Completed
Failed

Lessons I Learned

Building this pipeline taught me that machine learning isn't only about models.

It's also about:

System design
APIs
Background jobs
Queues
Scalability
Fault tolerance

Good infrastructure lets researchers spend more time improving models and less time waiting for them.

Key Takeaways

✅ Train experiments in parallel instead of sequentially.

✅ Use queues to avoid blocking APIs.

✅ Background workers improve scalability.

✅ Docker ensures consistent environments.

✅ Backend engineering is a huge part of modern machine learning.

Final Thoughts

Building this project helped me realize that the biggest bottleneck in machine learning isn't always the model itself.

Sometimes it's the system around it.

Designing scalable infrastructure for training, scheduling, and monitoring experiments can make a much bigger difference than tweaking another hyperparameter.

If you're learning machine learning, don't stop at training models. Learn how to build the systems that make those models usable in the real world.

💻 GitHub: https://github.com/Dakshanreddym

🔗 LinkedIn: https://linkedin.com/in/dakshan-reddy-m-105190271

Designing REST APIs That Are Easy to Maintain

Dakshan Reddy M — Tue, 04 Aug 2026 13:38:02 +0000

Designing REST APIs That Are Easy to Maintain

When building my first backend projects, I focused on making the API work. As my projects grew, I realized that working code isn't enough. An API also needs to be easy to understand, extend, and maintain.

A well-designed REST API saves time for both developers and users. Small design decisions made early can prevent major refactoring later.

In this article, I'll share a few practices that have helped me build cleaner backend applications.

What Makes an API Maintainable?

A maintainable API should be:

Easy to understand
Consistent across endpoints
Simple to extend
Easy to debug
Backward compatible whenever possible

The goal isn't to make the API clever. It's to make it predictable.

1. Use Clear Resource Names

Instead of:

GET /getUsers
POST /createUser
DELETE /deleteUser

Use resource-based endpoints:

GET    /users
POST   /users
GET    /users/{id}
PUT    /users/{id}
DELETE /users/{id}

The HTTP method already describes the action.

2. Use Proper HTTP Status Codes

Clients shouldn't have to inspect every response body to understand what happened.

Status	Meaning
200	Success
201	Resource Created
204	No Content
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
500	Internal Server Error

Example:

HTTP/1.1 201 Created

{
  "message": "User created successfully"
}

3. Keep Request and Response Formats Consistent

Instead of returning different JSON structures for every endpoint:

{
  "username": "Dakshan"
}

and

{
  "data": {
    "user": "Dakshan"
  }
}

Use one consistent format:

{
  "success": true,
  "data": {
    "id": 1,
    "name": "Dakshan"
  }
}

For errors:

{
  "success": false,
  "message": "User not found"
}

Consistency makes APIs easier to use and maintain.

4. Version Your APIs

Applications evolve over time.

Instead of changing existing endpoints:

/users

Version them:

/api/v1/users
/api/v2/users

Older applications continue working while newer ones can adopt the latest version.

5. Validate Input

Never assume incoming data is correct.

Example:

{
  "email": "abc"
}

Return a meaningful error instead of accepting invalid data:

{
  "success": false,
  "message": "Invalid email address"
}

Input validation improves both security and user experience.

6. Use Pagination

Avoid returning thousands of records in one request.

Instead of:

GET /users

Use:

GET /users?page=1&limit=20

Benefits:

Faster responses
Lower memory usage
Better scalability

7. Support Filtering

Instead of creating multiple endpoints:

/activeUsers
/adminUsers

Use query parameters:

GET /users?status=active
GET /users?role=admin

This keeps the API flexible and clean.

8. Separate Business Logic

A controller should stay small.

Bad:

Controller
    ↓
Validation
    ↓
Database
    ↓
Business Logic
    ↓
Response

Better:

Controller
    ↓
Service Layer
    ↓
Repository
    ↓
Database

This structure makes applications easier to test and maintain.

9. Return Useful Error Messages

Instead of:

{
  "error": "Something went wrong"
}

Return:

{
  "success": false,
  "message": "Email already exists"
}

Clear error messages reduce debugging time.

10. Document Your API

Documentation is part of the product.

Tools like Swagger/OpenAPI can automatically generate interactive documentation.

Include:

Endpoints
Parameters
Request examples
Response examples
Error codes

Example

Create User

POST /api/v1/users

Request

{
  "name": "Dakshan",
  "email": "dakshan@example.com"
}

Response

{
  "success": true,
  "data": {
    "id": 101,
    "name": "Dakshan",
    "email": "dakshan@example.com"
  }
}

Key Takeaways

Good REST APIs aren't just functional—they're predictable, scalable, and easy to maintain.

Here are the principles I follow:

✅ Use resource-based URLs
✅ Return proper HTTP status codes
✅ Keep request and response formats consistent
✅ Validate all input
✅ Support pagination and filtering
✅ Separate business logic from controllers
✅ Document every endpoint
✅ Version APIs when introducing breaking changes

Following these practices makes backend applications easier to develop, maintain, and scale as they grow.

Thanks for Reading! 👋

I'm passionate about Backend Development, Distributed Systems, and AI/ML Engineering. I enjoy building scalable software and sharing what I learn along the way.

GitHub: https://github.com/Dakshanreddym

LinkedIn: https://linkedin.com/in/dakshan-reddy-m-105190271

DEV Community: Dakshan Reddy M

🚀 What Happens When You Train 100 ML Models at Once?

🚀 What Happens When You Train 100 ML Models at Once?

The Problem

The Traditional Workflow

The Better Approach

Why Use a Queue?

Why Multiple Workers?

Docker Made Everything Easier

Monitoring Progress

Lessons I Learned

Key Takeaways

Final Thoughts

Tags

Designing REST APIs That Are Easy to Maintain

Designing REST APIs That Are Easy to Maintain

What Makes an API Maintainable?

1. Use Clear Resource Names

2. Use Proper HTTP Status Codes

3. Keep Request and Response Formats Consistent

4. Version Your APIs

5. Validate Input

6. Use Pagination

7. Support Filtering

8. Separate Business Logic

9. Return Useful Error Messages

10. Document Your API

Example

Create User

Key Takeaways

Thanks for Reading! 👋

Tags