{"title":"What is Machine Learning?","description":"","content":"Most modern applications you use today, from recommendations on Netflix to spam filters in your email, relies on systems that improve with data. Machine Learning is the field that makes this possible.\n\nInstead of explicitly programming every rule, we train models to learn patterns from data and make decisions or predictions. Whether it’s recognizing images, understanding text, or forecasting trends, machine learning shifts the focus from writing rules to learning from examples.\n\nThis chapter covers what machine learning actually is, how it differs from traditional programming, the main types of ML, and where it makes sense to use it (and where it doesn't).\n\n---\n\n# The Core Idea: Learning from Data\n\nTraditional programming and machine learning solve problems in fundamentally different ways.\n\nIn traditional programming, a developer studies the problem, figures out the rules, and writes code that implements those rules. The computer is just following instructions. Input goes in, rules are applied, output comes out.\n\nMachine learning flips this. You give the computer inputs along with the correct outputs (examples), and it discovers the rules by itself. Those learned rules are what we call a \"model.\" Once trained, the model can take new inputs it has never seen before and produce reasonable outputs.\n\n\n```mermaid\nflowchart TB\n subgraph ML[\"Machine Learning\"]\n direction TB\n D2[Data]:::primary --> A[ML
Algorithm]:::orange\n E[Expected
Output]:::primary --> A\n A --> M[Model]:::green\n end\n \n subgraph Traditional[\"Traditional Programming\"]\n direction TB\n R[Rules]:::orange --> P[Program]:::primary\n D1[Data]:::primary --> P\n P --> O1[Output]:::green\n end \n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n**The key difference:** in traditional programming, the developer encodes domain knowledge as logic. In ML, the developer encodes domain knowledge as training data, and the algorithm extracts the logic.\n\n\n> **House Pricing**\n>\n> Consider house pricing. You could write rules based on square footage, number of bedrooms, and location. But in reality, hundreds of subtle factors interact. \n>\n> The quality of nearby schools, walkability, proximity to transit, neighborhood trends, even the direction the house faces. These factors combine in ways that are hard to express as if-else statements.\n>\n> An ML model trained on historical sales data captures these interactions without anyone writing the rules. It learns that a 3-bedroom house near a top-rated school in a walkable neighborhood with south-facing windows is worth more than raw square footage would suggest.\n\n\n#### **So what does \"learning\" actually mean here?** \n\nAt its core, the model has internal parameters (think of them as millions of adjustable knobs). During training, the algorithm tweaks these knobs to minimize the gap between what the model predicts and the correct answers in the training data.\n\nOver thousands of iterations, the model gets better at capturing the patterns that matter. Once the knobs are set, the model can generalize to new data it has never seen.\n\nThis is both the power and the limitation of ML. The model can only learn patterns that exist in the training data. If your house pricing data only includes sales from California, the model won't know how to price homes in Texas.\n\n---\n\n# Types of Machine Learning\n\nWith the core idea of learning from data in place, the natural question is: what kind of data, and what kind of learning?\n\nThere are three main paradigms, each suited to different problems.\n\n#### **Supervised learning**\n\n**Supervised learning** is the most common type in production systems. You give the model labeled examples, input-output pairs where the correct answer is known. The model learns to map inputs to outputs. \n\n**Example:** Email labeled spam or not-spam, houses labeled with sale prices, images labeled with object names. The \"supervised\" part means that you need to provide the right answers during training.\n\n#### **Unsupervised learning**\n\n**Unsupervised learning** works with unlabeled data. There are no labels or correct answers. Instead, the model finds hidden structure on its own. Clustering is the classic example: given a million customers with purchase histories, group them into segments that share similar behaviors. Nobody told the model what the segments should be.\n\nOther examples include anomaly detection (finding data points that don't fit any pattern) and dimensionality reduction (compressing high-dimensional data into something manageable). Unsupervised learning is valuable when you don't know what patterns exist yet and want the data to tell you.\n\n#### **Reinforcement learning**\n\n**Reinforcement learning** takes a completely different approach. An agent interacts with an environment, takes actions, and receives rewards or penalties. Over time, it learns a strategy that maximizes cumulative reward. \n\nThink of it like training a dog: good behavior gets a treat, bad behavior doesn't. This is how AlphaGo learned to play Go, how robots learn to walk, and how self-driving cars learn driving policies.\n\nReinforcement learning shows up less often in typical ML system design interviews, but it is important to know it exists, especially for problems involving sequential decision-making.\n\n\n```mermaid\nflowchart TD\n ML[Machine
Learning]:::primary\n\n SL[Supervised
Learning]:::orange\n UL[Unsupervised
Learning]:::teal\n RL[Reinforcement
Learning]:::red\n\n SL1[Classification]:::green\n SL2[Regression]:::green\n\n UL1[Clustering]:::green\n UL2[Anomaly
Detection]:::green\n\n RL1[Game AI]:::green\n RL2[Robotics]:::green\n\n ML --> SL\n ML --> UL\n ML --> RL\n\n SL --> SL1\n SL --> SL2\n\n UL --> UL1\n UL --> UL2\n\n RL --> RL1\n RL --> RL2\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nHere is a quick comparison of the three types:\n\n\n| Type | Data | Goal | Common Examples |\n| ------------- | ---------------------------------- | ------------------------------- | ------------------------------------------------ |\n| Supervised | Labeled (input + correct answer) | Predict outcomes for new inputs | Spam detection, price prediction, search ranking |\n| Unsupervised | Unlabeled (input only) | Discover hidden patterns | Customer segmentation, anomaly detection |\n| Reinforcement | Rewards/penalties from environment | Maximize long-term reward | Game AI, autonomous driving, robotics |\n\n\nWe will cover supervised and unsupervised learning in much more depth in the next section of this course. For now, the key takeaway is that the type of learning you choose depends on what data you have and what problem you are solving.\n\n---\n\n# Where ML Adds Value (and Where It Doesn't)\n\nNot every problem needs machine learning. This might seem obvious, but it is one of the most common mistakes in practice and in interviews. Reaching for ML when a simpler approach works is a red flag.\n\n**The core principle:** ML is the right tool when the rules governing a problem are too complex, too numerous, or change too fast for humans to write and maintain. Traditional software is better when the logic is well-defined, deterministic, and stable.\n\n\n| Signal | Use ML | Use Traditional Software |\n|--------|--------|--------------------------|\n| Rule complexity | Patterns are too subtle or numerous to codify | Logic fits in a rules engine or lookup table |\n| Rate of change | Patterns shift weekly or daily (fraud, spam) | Rules change quarterly at most |\n| Scale of patterns | Millions of user preferences or behaviors | Dozens of business rules |\n| Error tolerance | Approximate answers are acceptable (recommendations) | Exact answers required (financial calculations) |\n| Data availability | Thousands or millions of labeled examples exist | Little or no meaningful training data |\n| Explainability needs | Approximate explanations are acceptable | Every decision must be fully justified |\n\n\nSome problems are better solved with simple logic. Calculating sales tax is a good example. Rates are defined and rarely ambiguous, so a lookup table works perfectly. Adding ML would only make the system harder to maintain and less reliable.\n\nOther problems don’t fit clean rules. Fraud detection is one of them. Patterns change constantly, and static rules miss new attacks. ML models can pick up subtle signals like unusual transaction patterns, location mismatches, or device behavior, and adapt as those patterns evolve.\n\nIn practice, production systems combine both. An ML model might assign a risk score, while hard rules enforce strict constraints, like blocking transactions from sanctioned regions. The model handles ambiguity. The rules provide guardrails.\n\nThere’s also a cost to ML. It requires data pipelines, training infrastructure, serving systems, and ongoing monitoring. If a problem can be solved with simple logic, that’s usually the better choice. Use ML when the complexity truly demands it.\n\n---\n\n# Real-World ML Systems\n\nTo make this concrete, here are four domains where ML has become essential, and in each case, why rules alone would not work.\n\n### Recommendation Engines\n\nWhen you open Netflix, YouTube, or Spotify, the content you see is personalized. With millions of items in the catalog and millions of users, each with unique preferences, no team of curators could manually match users to content. Showing everyone the most popular items is a decent baseline, but it treats every user identically. A jazz fan and a hip-hop fan opening Spotify should see entirely different playlists.\n\nML models learn individual preferences from behavioral signals: what you watched, how long you watched it, what you skipped, what you searched for. They combine these signals with item features (genre, creator, recency) to predict what you are most likely to engage with next.\n\nThe following diagram shows a simplified version of how recommendations work:\n\n\n```mermaid\nflowchart LR\n A[User Opens
App]:::primary --> B[Fetch User
History]:::primary\n B --> C[Candidate
Generation
ML Model]:::orange\n C --> D[Ranking
ML Model]:::orange\n D --> E[Display
Recommendations]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe system first generates a broad set of candidates (hundreds from millions) using a fast, lightweight model. Then a more powerful ranking model scores those candidates and orders them by predicted relevance. This two-stage approach is a recurring pattern across ML systems.\n\n### Search Ranking\n\nA query like \"running shoes\" on Amazon returns thousands of results. Which ones appear on the first page determines whether a user finds what they want or leaves frustrated. Simple keyword matching gets you a baseline, but it does not account for relevance, user intent, product quality, or personalization.\n\nML ranking models take in dozens of features: how well the query matches the product title and description, the product's rating and review count, the user's purchase history and browsing behavior, the product's sales velocity, and more. The model learns which combinations of these features predict a click or purchase. Google's search ranking uses hundreds of such signals, continuously updated as user behavior evolves.\n\n### Fraud Detection\n\nBanks and payment processors handle millions of transactions per second. Fraudsters are creative and constantly change tactics. A rule that catches today's fraud pattern might be useless next month.\n\nML models learn subtle signals that rules cannot easily capture. A transaction from a new device in an unusual location, at an unusual time, for an unusual amount, all within seconds of a password change, is suspicious. Any single signal might be innocent. The combination is what matters, and ML models excel at learning these multi-factor patterns. They also adapt as new fraud techniques emerge, because the model can be retrained on recent labeled examples.\n\n### Self-Driving Cars\n\nDriving involves thousands of simultaneous decisions in a constantly changing environment. No set of if-else rules can anticipate every combination of road conditions, pedestrian behavior, weather, and traffic patterns.\n\nSelf-driving systems use multiple ML models working together. Perception models detect objects from camera and lidar data: other cars, pedestrians, lane markings, traffic signs. Prediction models forecast what other road users will do in the next few seconds. Planning models decide what action the car should take given the current state and predictions. This is an example of multiple ML models composing a larger system, each solving a piece of the overall problem.\n\nHere is a summary of these four applications:\n\n\n| Application | ML Task | Why Not Rules? | Scale |\n|-------------|---------|----------------|-------|\n| Recommendations | Predict what a user wants to see or buy | Billions of user-item combinations | Netflix: 200M+ users, 15K+ titles |\n| Search Ranking | Order results by predicted relevance | Relevance depends on context, user, intent | Google: 8.5B+ searches per day |\n| Fraud Detection | Flag suspicious transactions | Fraud patterns change constantly | Visa: 65K+ transactions per second |\n| Self-Driving Cars | Perceive, predict, and plan in real time | Infinite driving scenarios | Waymo: millions of autonomous miles driven |\n\n\nIn each case, the pattern is the same: the problem involves too many variables, too many combinations, or too much change for hand-written rules to keep up. That is where ML shines.\n\n---\n\n# Quiz","pageType":"ml-system-design"}

What is Machine Learning?

Get Premium