Machine learning design patterns come from repeated problems seen across customers, developers, and production ML teams.
2
Teams should adopt infrastructure as their needs grow instead of building complex systems before they need them.
3
MLOps covers the data, models, deployment systems, and decision-making processes around ML, while model ops focuses mainly on the model.
Summary
Valliappa Lakshmanan explains why machine learning needs its own catalog of design patterns. The patterns come from repeated problems seen while working with customers, Google teams, and developers. He discusses how patterns help teams handle data preparation, feature reuse, model development, deployment, scaling, maintainability, and stakeholder needs. Lakshmanan argues that infrastructure should match a company's maturity. A managed prediction service and a standard Python environment may be enough early on, while a feature store or more advanced tooling becomes useful when reuse and freshness requirements justify the added complexity. He also describes how ML design problems extend familiar software engineering problems because teams must version data, model artifacts, and code together. The discussion covers when a technique becomes a reusable pattern, why data scientists should not be expected to understand low-level infrastructure, and why software engineers with enough ML knowledge may fit production roles better than research-oriented data scientists.
Lakshmanan describes his work on severe weather prediction, including tornadoes, hail, lightning, and flash floods. He approached technology as a tool for understanding weather and supporting decisions. An airport might use weather information to decide whether to stop landing flights after a nearby lightning strike. An emergency manager might use it to decide whether to sound a tornado siren. His point is that scientists increasingly write software to run simulations and make decisions, but the software is not the final goal. The same view shapes his approach to ML systems: infrastructure should help people solve a problem rather than become the problem they have to manage.
Teams should start with the infrastructure they need now
Lakshmanan describes an ML maturity model based on work with customers. He says a company does not always need feature stores, its own Kubernetes clusters, or a full experimentation framework. A managed prediction service and a standard Python development environment can be enough for an early-stage team. Many companies initially use a model from TensorFlow Hub or apply transfer learning instead of developing highly bespoke models. Their infrastructure and recording needs may therefore be limited. Lakshmanan advises teams to get moving rather than spend a long time building systems they may never need. They can move to more advanced infrastructure as their models, data, and operational needs grow.
A feature store is justified by repeated reuse and freshness
Lakshmanan explains that a feature store supports reuse of calculations across multiple models. He gives the example of Gojek, where many models used information about drivers, such as their history, preferences, and delivery times. A shared feature could let each model request an embedding for a driver rather than independently rebuilding the calculation. He compares the decision to choosing between code inside a function, a reusable library, and a microservice called through an API. A feature store is the microservice-level option. It makes sense when many models need the same feature and the information must stay up to date. For less demanding reuse, a library and a pipeline may be enough.
Tools can encode patterns while leaving the reasoning to the engineer
Some ML design patterns appear in tools, libraries, or managed services. Lakshmanan uses TensorFlow's embedding column as an example. The API makes it easier to turn a sparse structured field into an embedding without manually creating a dense layer. Engineers still need to understand why they are using an embedding. Applying one to every one-hot encoded column can discard information when the closeness relationship between values is not meaningful. Managed prediction services encode another pattern by accepting model artifacts, running stateless predictions, and handling scaling. Distribution strategies sit between libraries and services. The tool handles the difficult work, while the engineer chooses whether a model should be split across nodes or mirrored.
Patterns are selected from repeated problems across contexts
The authors of the book found patterns by working with companies in different industries, teaching engineers through Google's ML Immersion program, and studying how internal Google teams productionized ML models. They looked for problems that appeared across retail, finance, conservation, and other settings. Lakshmanan also began with blog posts explaining why APIs existed, including the need to keep transformations consistent between training and prediction. A pattern must be reusable in more than one context and implementable in more than one way. He gives MediaPipe as an example of an interesting pipeline approach that was not included because the team had not seen a second similar use case. A technique can become a pattern as more teams repeat it.
ML design patterns apply at different stages of the ML life cycle
Lakshmanan does not see the patterns as a fixed hierarchy. He describes them as handoffs across the ML life cycle. Teams first need to represent and prepare data well, then incorporate it into models, compare experiments, handle imbalance, and choose suitable representations such as feature crosses or embeddings. Deployment introduces different scaling problems. Serving millions of users at once is different from making predictions for millions of instances quickly. After deployment, teams need to address explainability, reuse, maintainability, and how users make decisions with model outputs. The relevant pattern depends on the stage and the current need. A feature store is not automatically more important than a serving pattern.
ML systems extend familiar software engineering concerns
Lakshmanan agrees that many ML problems are software engineering problems, but ML adds specific constraints. Maintainability covers code and data, and both can change independently. Teams need to keep data, model artifacts, and code linked through metadata so they can reproduce what happened. Version control is familiar in software engineering but is often less consistently applied to data science. ML teams need to version the data, the artifacts produced from it, and the code that produced them. This is why ML design patterns often adapt established software practices rather than inventing entirely new ones. The scope is wider because the system's behavior depends on both the software and the data used to train it.
Production ML roles need both software and ML knowledge
Lakshmanan says he has seen strong SREs and data engineers become effective ML engineers. He has seen fewer data scientists make that transition successfully, because many data scientists prefer exploratory work and may not enjoy the operational detail required for production systems. For smaller companies that need to build and deploy models quickly, he recommends hiring software engineers who can learn enough ML and data science. Research-oriented data scientists are a better fit when the company wants exploratory work with an uncertain destination. Hiring a data scientist for operational production work can create a mismatch between the person's interests and the company's needs.
"To me a pattern is something that is applicable in multiple contexts, in multiple industries, whether it's NLP or it's images or it's something else."Valliappa Lakshmanan40:41
Who should watch
You are deciding whether your ML platform needs a feature store, a managed prediction service, or a larger experimentation system.
Your team is turning research code into production systems and needs a way to think about data, model, deployment, and maintenance patterns together.
You are hiring or defining an ML engineer role and need to separate exploratory data science work from production software work.
