GR for ML, Quality Attributes, and System Architecture
4.1 Review and GR for ML Framework
4.1.1 Overview and Motivation
Hook: How do you ensure that a software architect in Tokyo, a data scientist in Berlin, and a product manager in Mumbai all picture the same system when they read a requirements document? Without a shared notation, each person fills the gaps with their own assumptions — and those assumptions collide during integration.
The GR for ML framework is a modelling notation for requirements engineering in machine learning systems. The professor draws a direct parallel: just as UML (Unified Modeling Language) gives traditional software engineers a standard set of diagrams — class diagrams, sequence diagrams, state charts — that any practitioner worldwide can read unambiguously, GR for ML provides notations purpose-built for ML use cases. When a designer or architect produces a model using these notations, any other designer or architect anywhere in the world can interpret it the same way. This shared vocabulary is the core value: it removes ambiguity in how requirements are articulated and documented.
Intuition: Think of GR for ML as a common language blueprint for ML projects. Just as an architect's floor plan tells a builder exactly where walls go — regardless of which country they are in — GR for ML diagrams tell every stakeholder exactly what the ML system needs, what data it consumes, and what quality constraints apply. The notation is the contract; the system is the building.
The framework is structured as multiple views, each capturing a different aspect of an ML system. A view is an abstraction — a deliberate lens that shows certain details and hides others, much like a city's cycling map shows bike lanes but hides tourist attractions. In the previous session, the business view was covered. The business view captures:
- The highest-level business goals (what the organization wants to achieve)
- The decision goals that flow from those business goals (what decisions need to be made)
- The data entities involved (what data is needed)
The running example throughout this discussion is a credit risk prediction system at a bank, where a case worker (bank employee) processes loan applications and must take a final decision — approve or reject — on each credit application.
In the business view for this example:
- Data needed: the applicant profile (demographic information, employment history, income, existing debts)
- Model: a predictive model built using historical data (from the last 48 months) with labeled outcomes (approved/rejected and whether the applicant defaulted)
- Refresh cadence: the model is refreshed monthly
- Output: each new applicant's credit risk is classified as high or low
Worked Example — Credit Risk System (Business View):
A bank processes loan applications. The case worker needs to decide: approve or reject.
- Business goal: Minimize loan defaults while maintaining approval volume
- Decision goal: For each applicant, classify credit risk as high or low
- Data entity: Applicant profile (age, income, employment history, existing debts)
- Model: Predictive classifier trained on 48 months of historical data with labeled outcomes
- Refresh: Model retrained monthly to capture changing economic conditions
Sense-check: The business view does not specify which algorithm or how to clean the data — it only captures what the system needs to achieve and what data it operates on. The "how" comes in the next two views.
The GR for ML View Structure:
| View | What it captures | Analogy |
|---|---|---|
| Business View | Goals, decisions, data entities | Why are we building this? |
| Analytics Design View | Analytics goal, algorithms, indicators, soft goals | What kind of prediction and how do we evaluate it? |
| Data Preparation View | Cleaning, reduction, pre-processing algorithms | What happens to the raw data before modeling? |
Each view is like a different floor of the same building — they all belong to one structure, but each serves a distinct purpose. You would not confuse the ground floor (business goals) with the analytics lab on the second floor.
The remaining views — analytics design view and data preparation view — form the core of this session, followed by a transition into quality attributes and system architecture.
Recap: GR for ML is a multi-view modelling notation that brings the same unambiguous communication to ML systems that UML brings to traditional software. The business view (covered previously) sets the "why"; the analytics design and data preparation views (covered next) define the "what" and "how." Every view feeds into the next — business goals determine analytics goals, which determine data needs.
4.2 Analytics Design View
4.2.1 Purpose and Structure
Hook: You know what the business wants (approve or reject loan applications). But the business view says nothing about how to make that prediction. Should you use a decision tree? A neural network? A simple rule? The analytics design view is where you answer that question — and, critically, how you will know if your answer is any good.
Once the business view captures the user requirements — the applicant profile, the high-level goal of deciding on credit applications — the next question is: what kind of analytics can I apply? Different use cases call for different forms of analytics. The main types are:
- Predictive analytics — classification, regression, forecasting. The credit risk example is a clear case of predictive analytics because the output is a discrete label (high/low risk). Predictive analytics asks: given what we know, what will happen?
- Descriptive analytics — summarizing historical data using basic statistical tools. Descriptive analytics asks: what happened? Examples include dashboards showing average loan approval rates by region, or monthly trend charts.
- Diagnostic analytics — digging into why something happened, again primarily statistical. Diagnostic analytics asks: why did it happen? For instance, why did default rates spike in Q3?
- Prescriptive analytics — recommending actions based on predictions. Prescriptive analytics asks: what should we do about it? For example, automatically adjusting interest rates based on predicted risk.
The Analytics Design View captures four elements:
- Analytics goal — which type of analytics is needed (predictive, descriptive, diagnostic, prescriptive)
- Algorithms — the candidate techniques that can achieve that goal
- Indicators/metrics — how algorithm performance will be evaluated
- Soft goals — quality attributes or non-functional requirements that constrain the solution (shown with a cloud-like notation in the GR for ML diagrams)
In the credit risk example:
- Analytics goal: classification of applicant profile (a type of predictive analytics)
- Indicators: accuracy and precision (among others — recall and F1 score are also relevant)
- Candidate algorithms: support vector machine (SVM), Naive Bayes, and decision trees — any number can be listed; there is no restriction
- Soft goals: robustness and tolerance to missing values, with tolerance to missing values influencing (leading to) robustness
Within the notation, the analytics goal connects to algorithms with a relationship that reads as "the algorithm is a kind of presence algorithm." This is similar to the UML is-a (generalization/inheritance) relationship.
4.2.2 Analytics Goal Types and Notation
The notation uses a generalization/inheritance relationship (similar to the UML "is-a" relationship) to represent that description goal, prediction goal, and prescription goal are each a type of analytics goal. This is an inheritance hierarchy:
Analytics Goal
├── Description Goal
├── Prediction Goal
└── Prescription GoalFor a given dataset, the analytics goal will typically be one of these kinds — determined by the use case — though it is not impossible for a system to combine multiple types. For instance, a credit risk system might primarily use prediction (classify as high/low risk) but also include descriptive analytics (historical default rates by demographic) in its dashboard.
Once the analytics goal is identified as predictive, the next question is: which algorithm should be applied? For classification, the options include SVM, Naive Bayes, or any of the artificial neural network variants. The choice is not arbitrary — it depends on the data characteristics, the interpretability requirements, the available compute resources, and the quality constraints.
The soft goals (marked with a cloud-like notation) represent non-functional quality attributes that will be discussed at length later in this and subsequent sessions. Think of them as constraints on how the prediction must be made, not just what the prediction is.
4.2.3 Trade-offs and Algorithm Selection
Intuition: Choosing an algorithm is like hiring an employee. You set a minimum qualification (the threshold), interview several candidates (run the algorithms), and select those who meet the bar. You do not automatically pick the one with the highest score — you first eliminate anyone who does not meet the minimum. The threshold is the filter; the indicators are the interview questions.
When multiple algorithms are candidate solutions for the same analytics goal, the indicators become the selection criteria. A threshold is set for each indicator — for example, 85% accuracy. If an algorithm fails to meet that threshold, it is eliminated from consideration. The algorithm (or algorithms) that exceed the threshold advance. This is a filtering mechanism, not an automatic tie-breaker — it reveals which algorithms are viable given the quality bar.
Worked Example — Algorithm Selection for Credit Risk:
Suppose three candidate algorithms are evaluated on a held-out test set of 1,000 loan applications:
| Algorithm | Accuracy | Precision | Meets 85% accuracy threshold? |
|---|---|---|---|
| Decision Tree | 82% | 79% | No — eliminated |
| Naive Bayes | 87% | 83% | Yes — advances |
| SVM | 91% | 88% | Yes — advances |
Process: Set the accuracy threshold at 85%. Run each algorithm on the same test data. Decision tree (82%) is eliminated. Naive Bayes (87%) and SVM (91%) both advance. If a second criterion (say, precision ≥ 85%) is added, Naive Bayes (83% precision) would also be eliminated, leaving SVM as the sole candidate.
Sense-check: The threshold is a minimum bar, not a ranking. A higher accuracy does not automatically win — it must also meet all other indicator thresholds. This is why multiple indicators matter.
4.2.4 Student Questions and Answers
Q: When you say tolerance to missing values, what do you mean? Generally, for missing values, we use techniques like average or mean. How does tolerance fit?
A: Consider age as a column in the applicant profile. Some fields are mandatory (age cannot be missing), but some fields collected from the user are non-mandatory. If you are using decision tree as the algorithm, it takes multiple features. If a feature has many missing values, you set a tolerance threshold — say 50% or 60%. If the percentage of missing values exceeds that tolerance, you may not be able to select that feature at all. Tolerance to missing values means: how much missing data are you willing to accept for a feature before discarding it? This tolerance influences robustness — a model that tolerates more missing data is more robust.
Q: So accuracy and precision are the criteria used for evaluating classification algorithms?
A: Yes. For any classification problem, accuracy, precision, recall, and F1 score are all important criteria to assess. (These will be defined precisely in Section 4.4.)
Q: What do the plus-minus symbols mean in the notations?
A: It means "leads to" or "influences." For example, tolerance to missing value leads to robustness. It is not positive or negative — it is a directional influence relationship. In GR for ML diagrams, this is drawn as an arrow with a ± symbol, indicating that one soft goal contributes to (supports) another.
Q: So we define the boundary — what accuracy we need — and if an algorithm doesn't achieve it, that algorithm is not used. We set a threshold and select accordingly?
A: Correct. You set a threshold, run the different algorithms, and select based on what matches or exceeds it.
Q: What is the interpretability of the model here?
A: Interpretability and explainability go hand in hand. It is about being able to understand why a model made a particular decision. For basic machine learning models, interpretability varies greatly:
- A decision tree is highly interpretable — you can trace the path from root node to leaf, and even hand-compute the reasoning. Every branch and split is visible.
- A neural network for the same applicant profile classification can have quite low interpretability — you will have difficulty interpreting every decision the model makes. Some models let you see exactly how decisions are reached; others behave as a black box.
Interpretability will be discussed in greater depth when the soft goals/quality attributes section arrives.
Pitfall — Confusing "algorithm" across views: In the analytics design view, "algorithm" means classification or regression techniques (SVM, Naive Bayes, decision trees). In the data preparation view (Section 4.3), "algorithm" means pre-processing techniques (normalization, encoding, feature selection). Do not conflate the two — they operate at different stages of the pipeline.
Recap: The analytics design view answers what kind of analytics and which algorithms to use. It specifies the analytics goal (typically one of prediction, description, or prescription), lists candidate algorithms, defines evaluation indicators with thresholds, and captures soft goals (quality constraints). Algorithm selection is a filtering process: indicators with thresholds eliminate candidates that do not meet the quality bar. Interpretability — how transparently a model's reasoning can be understood — varies dramatically across algorithm families and is a key soft goal.
4.3 Data Preparation View
4.3.1 Purpose
Hook: A common saying in data science is "garbage in, garbage out." No matter how sophisticated your algorithm, if the data feeding it is messy, incomplete, or inconsistent, the predictions will be unreliable. The data preparation view is where you plan how to turn raw data into something an algorithm can actually learn from.
For any machine learning application, data is everything. Without input data, no meaningful analytics can be performed. The data preparation view describes how raw data is readied before it ever reaches the analytics stage. It answers practical questions:
- What cleaning steps are needed? (handling missing values, fixing formatting, removing duplicates)
- What reduction techniques should be applied? (dimensionality reduction, feature selection)
- What pre-processing algorithms will transform the raw data into a form the analytics algorithm can consume?
The data for the credit risk example is the applicant profile — primarily text data (demographic information, gender, qualifications, salary). But the data preparation view is generic: the data entity could be image data, speech data, or any other format depending on the application.
Intuition: Think of data preparation as cooking prep before the actual cooking. Raw vegetables (data) need to be washed (cleaned), peeled (outlier removal), and chopped into uniform pieces (normalization, encoding) before the chef (the algorithm) can use them. A Michelin-star recipe (SVM, neural network) will fail if the ingredients are dirty or inconsistently cut.
4.3.2 Components
The Data Preparation View centers on the data preparation task, which has two sub-tasks:
- Data cleaning — removing inconsistencies, handling outliers, fixing formatting issues, dealing with missing values
- Data reduction — reducing the dimensionality or volume of data before it passes to the analytics stage. This may or may not be required depending on the use case.
The data entity is the raw data source — it could be a table in a relational database, items in a MongoDB collection (NoSQL), a set of image files, or any other representation. The data preparation task operates on this entity.
There are two important supporting elements in the notation:
- Mechanism — the process or way in which the operation is carried out (e.g., "encoding categorical variables")
- Algorithm — the actual technique for pre-processing (e.g., one-hot encoder, label encoder, min-max normalization)
Pitfall — "Algorithm" means different things in different views: In the analytics design view, "algorithm" means classification or regression techniques like SVM or Naive Bayes. In the data preparation view, "algorithm" means pre-processing techniques: normalization, encoding, feature selection, and so on. These are distinct concepts that happen to share the same label. Always check which view you are in.
Worked Example — Data Preparation for Credit Risk:
The raw applicant profile contains:
| Feature | Type | Issue |
|---|---|---|
| Age | Numeric | Some entries are 0 or negative (data entry errors) |
| Gender | Categorical | Values: "M", "F", "Male", "Female", "male" (inconsistent) |
| Monthly salary | Numeric | Some entries have commas, some do not (formatting) |
| Employment type | Categorical | Values: "Salaried", "Self-employed", "Government" |
Step 1 — Data Cleaning:
- Age: Remove rows where age ≤ 0 or age > 100 (outlier removal)
- Gender: Standardize to "Male"/"Female" (formatting consistency)
- Monthly salary: Strip commas and convert to float (formatting fix)
- Employment type: No issues — already consistent
Step 2 — Data Reduction:
- Apply one-hot encoding to categorical features (Gender, Employment type) to convert them to numeric form
- Normalize numeric features (Age, Monthly salary) to a 0–1 scale using min-max normalization so that salary (in lakhs) does not dominate age (in decades)
Sense-check: After cleaning and encoding, every feature is numeric, consistently formatted, and on a comparable scale — ready for the analytics algorithm.
For example, if a dataset contains categorical values like gender (male/female), an encoding algorithm — one-hot encoder or label encoder — converts them to numeric form. Normalization may also be applied depending on the data. These are very generic notations; they specify what kind of operation to do, not which specific technique to use. The block is a template — within it, you can apply any data cleaning or reduction technique appropriate to the data entity.
Data reduction can include feature engineering. Not all features have the same influence on the outcome variable, so feature importance techniques help identify which features matter. Principal Component Analysis (PCA) is another reduction technique that transforms high-dimensional data into a lower-dimensional representation while preserving the most important variance. The data that survives reduction then moves into the analytics stage for classification or regression.
4.3.3 Top-Down vs Bottom-Up Approaches
Q: Is GR for ML a top-down approach or bottom-up approach? How should we interpret it given the various actors at different stages?
A: It can be used in both ways, and both are valid.
A top-down approach starts from the business problem. A business group identifies a problem that can be solved through ML techniques. They start with the goal, without looking at algorithms or data yet. From that goal, they trace downward: what data is available, what processing can be done, what kind of prediction is possible. This is business-centric.
A bottom-up approach starts with existing data. You have data — perhaps in the form of PDFs or other repositories — and you ask: using this data, how can I create a business view that makes it meaningful to the enterprise? A real-world example is the RAG (Retrieval Augmented Generation) approach: you have data in PDFs, you create a RAG model that provides a chatbot interface, and any user can query and retrieve information from that data. Starting from the data, you arrive at an overall strategic goal. This is engineering-centric.
Both approaches are visible in MTech dissertation work. Some students work with a supervisor who provides the business goal; the student then navigates the pipeline to achieve it (top-down). Other students already have exposure to certain data, work with it continuously, and then — with their supervisor — formulate a research goal that utilizes that data for predictions (bottom-up). Both are legitimate paths.
Q: This seems specifically for traditional machine learning — credit risk, classification. Does it change for neural networks where data preparation is minimal?
A: The framework is applicable across predictive AI, generative AI, and agentic AI. The only difference is that certain blocks may be left out. If the data is already clean, there is no need for the data cleaning block. The notation is a template — remove what is not needed.
Q: Are these diagrams drafted to make a decision, or after the decision as documentation of what is going to be done? How to utilize them?
A: Two purposes. First, documentation — even as we moved from waterfall to agile and reduced formal documentation, somewhere you still need to record the decisions taken. These views serve as that record. Second, clarity — when you produce this kind of diagram, an architect, a designer, or a developer will all have the same understanding of the system. This is the advantage of any modelling notation. Even with UML, a class diagram cannot be misinterpreted — the relationships (aggregation, inheritance) are unambiguous, so the implementation in Java, C#, or Python will follow the same structure.
Q: What does the operator notation mean? How does the operator apply different algorithms?
A: The operator represents iteration — you may need to apply multiple data preparation algorithms to the same dataset. If it were a one-to-one relationship (one algorithm per task), you could connect the algorithm directly to the data preparation task without the operator. The one-is-to-many relationship (the "operator" notation) signals that for the same data entity, you might run image-specific preprocessing, text-specific preprocessing, and speech-specific preprocessing — multiple operations happening in parallel or sequence.
Q: Can you explain what algorithms map to the description goal, prediction goal, and prescription goal? Can you generalize some algorithms to each category?
A: That is part of the exploration built into Assignment 1. The framework looks abstract at this stage, and that is intentional — it is to be explored. The assignment will cover the requirements material covered so far (business view, analytics design view, data preparation view), combined with quality attributes and system architecture from the upcoming sessions. Working in groups, you will map real use cases onto these views. The course provides the basics; the assignment is about deeper exploration.
Recap: The data preparation view plans how raw data is cleaned and reduced before it reaches the analytics stage. It has two sub-tasks (cleaning and reduction), operates on the data entity using mechanisms and pre-processing algorithms, and is distinct from the analytics design view. The framework supports both top-down (business goal → data) and bottom-up (data → business goal) approaches, and applies to all types of AI — not just traditional ML.
4.4 Measures, Metrics, Accuracy, and Precision
4.4.1 Measures and Metrics
Hook: You cannot improve what you cannot measure. If someone asks "is this algorithm good?", the only honest answer is "good relative to what?" — and that "what" must be a number. Measures and metrics turn vague goals into concrete, comparable quantities.
Throughout the GR for ML views, indicators appear — accuracy, precision, average resolution time, and others. These are all measurements or metrics. You cannot run any experiment without a goal to measure against. If you are evaluating three algorithms, you want a criterion such as "the algorithm with accuracy above 90% is selected."
A good measure or metric must satisfy three properties:
- Related to the goal — it must measure what you care about. If your goal is user satisfaction, measuring server uptime is a proxy at best.
- Quantifiable — expressed as a number. "The system feels fast" is not quantifiable; "95% of requests complete in under 2 seconds" is.
- Practical to collect — achievable with available data and resources. A metric that requires perfect ground truth for every prediction is impractical; one that uses a sample of labeled data is practical.
If the goal is vague — "improve chatbot usefulness" — you need to operationalize it with a measurable proxy. Operationalization means turning an abstract concept into a concrete, observable number.
Worked Example — Operationalizing a Vague Goal:
Vague goal: "Improve chatbot usefulness."
Operationalization steps:
- Give the chatbot to 100 users
- Conduct a survey with a satisfaction score on a Likert scale (1 to 5)
- Collect the average score
Result: Average satisfaction = 3.5. Target was above 3.0. Goal is met.
Sense-check: The abstract concept ("usefulness") has been turned into a concrete number (3.5 on a 5-point scale). This is how abstract goals become concrete metrics across every view: business, analytics, and data preparation.
Intuition: A metric is like a thermometer for your system. You cannot tell if someone has a fever by looking at them — you need a thermometer (the measurement tool) and a scale (the threshold, e.g., 37.5°C). Similarly, you cannot tell if an algorithm is "good" by looking at its code — you need a metric (accuracy, precision) and a threshold (e.g., 85%).
4.4.2 Accuracy versus Precision
These two terms are often conflated but mean different things in both general measurement and ML evaluation. The professor emphasizes this distinction because confusing them leads to wrong conclusions about model quality.
Accuracy vs. Precision — Two Distinct Concepts:
| Term | ML Definition | What it answers |
|---|---|---|
| Accuracy | Correctness of prediction — how many of the items predicted were correct | Out of all predictions, how many were right? |
| Precision | Quality of positive predictions — out of all items predicted as positive, how many were actually positive | When the model says "yes," how often is it actually "yes"? |
Formulas (ML context):
Where TP = True Positive, TN = True Negative, FP = False Positive, FN = False Negative.
There is also a broader measurement-theory distinction that the professor draws attention to:
- Accuracy (in measurement theory) describes the closeness to the true value.
- Precision (in measurement theory) describes the consistency of repeated measurements.
Worked Example — Accuracy vs. Precision in Measurement Theory:
Imagine a bathroom scale. You weigh yourself five times:
- Scenario A (precise, not accurate): Readings: 72.1, 72.1, 72.0, 72.1, 72.1 kg. Your true weight is 68 kg. The scale is precise (consistent readings) but not accurate (far from the true value).
- Scenario B (accurate, not precise): Readings: 68.2, 67.5, 68.8, 67.9, 68.1 kg. Your true weight is 68 kg. The scale is accurate (close to true value on average) but not precise (readings vary).
- Scenario C (both): Readings: 68.0, 68.0, 68.0, 68.0, 68.0 kg. Consistent and correct.
Sense-check: In ML, we typically want both — but precision (consistency) without accuracy can be misleading. A model that always predicts "not fraud" is precise (consistent output) but misses all actual fraud.
Q: (Student paraphrase of accuracy vs precision in ML terminology) Accuracy states how many out of all predictions were correct overall. Precision would be: whatever is predicted positive, how many were actually positive.
A: Perfect. That is exactly the distinction.
Pitfall — High accuracy can hide poor performance on minority classes: In a dataset where 95% of applicants are non-defaulters, a model that predicts "no default" for everyone achieves 95% accuracy — but 0% precision for the default class. This is why precision (and recall, F1) matter alongside accuracy, especially in imbalanced datasets.
Recap: Metrics turn vague goals into measurable numbers. A good metric is related to the goal, quantifiable, and practical to collect. Accuracy measures overall correctness; precision measures the quality of positive predictions. In measurement theory, accuracy is closeness to truth; precision is consistency of repeated measurements. Both matter, and high accuracy alone can mask poor performance on minority classes.
4.5 Quality Attributes — General
4.5.1 Introduction: Why Quality Attributes Matter
Hook: On October 6, 2014, India's largest e-commerce site launched its biggest sale ever — and within hours, the website crashed, money vanished from customer accounts, and orders disappeared. Five years later, a streaming service handled 25.3 million concurrent users without a glitch. The difference was not the code — it was the architecture, driven by quality attributes.
Two case studies establish why quality attributes are critical — and why getting them wrong causes spectacular failure.
Flipkart Big Billion Day — 2014 (Failure): On October 6, 2014, Flipkart launched one of India's first mega-sale events with deep discounts across 70-plus categories. The result was disastrous:
- The website crashed under massive traffic
- Already-selected products vanished from shopping carts after recovery, or appeared as sold out
- Money was deducted from accounts but orders were not executed
- Customer complaints flooded in; reviews were hidden; no refund or cancellation was possible
The root causes: (1) key quality attributes were not identified — the system was not designed for the load it would face. (2) The system architecture was wrong — Flipkart was running a monolithic architecture that could not scale. After this failure, Flipkart migrated to a microservices architecture, and today their Big Billion Day events succeed at enormous scale. Failure taught the lesson.
Scope — What went wrong at Flipkart: The functional requirements were met — the app could list products, take orders, and process payments. But the quality requirements (scalability, availability, reliability under load) were not addressed. A monolithic architecture that works for 10,000 users collapses at 10 million. The quality attributes were not identified, so the architecture was not designed to support them.
Hotstar — ICC Cricket World Cup 2019 (Success): During the India vs. New Zealand semi-final, Hotstar's OTT streaming service handled:
- Day 1: 13.9 million concurrent users when New Zealand was batting
- Day 2: A peak of 25.3 million concurrent users — the highest recorded concurrent viewership in history at that time (surpassing even YouTube, which had never crossed 18 million)
When MS Dhoni got out (the infamous run-out), viewership plummeted to about 4 million — but the system handled both the climb to 25.3 million and the sudden drop seamlessly.
How Hotstar succeeded:
- They used nine large AWS machines and distributed load across 8 AWS regions
- They performed tsunami testing — not simple load testing, but deliberately pushing the system to break points and then dropping load rapidly, exactly simulating match-day behavior
- Critically, they chose not to use AWS auto-scaling (they identified issues with auto-scaling for this specific use case)
- They prepared for selective scaling: the play microservice had to scale dramatically up and down, but other services (recommendation, homepage) also needed to be ready — when 25 million users closed the stream within 5 minutes and landed on the homepage, the recommendation service had to handle the sudden flood
The deeper scaling challenge is two-sided: Scaling up is hard, but scaling down is equally hard because (a) infrastructure costs must drop when demand drops, and (b) other microservices that didn't need to scale during the stream suddenly receive a surge as users navigate elsewhere. This phenomenon — demand shifting across services — exists in ML systems as well.
Q: How did Hotstar predict the footfall and decide how to scale?
A: As a company, you must be aware of certain events. A marquee India-New Zealand match has predictable viewership spikes. Similarly, Swiggy or Zomato know that December 31st or holidays bring more orders — they prepare scaling in advance. Predicting footfall is about organizational awareness of events that will drive traffic, then preparing architecture accordingly. Hotstar's specific preparation is detailed in a 45-minute video by their architect (shared with the class), covering machine provisioning, load distribution, and cross-service scaling.
Q: So it was selective scaling — the play microservice goes up and down, but other services remain at normal rates?
A: Correct. The other services operate at a "normal day" level, but they must still handle the surge when users leave the stream and land elsewhere. This selective scaling is what the architecture made possible.
Q: Does this happen repeatedly — like every IPL season?
A: Yes, but now — seven years later — everyone has learned. The first time (Flipkart 2014) was pioneering, and it failed. Today, companies know the patterns: when auto-scaling works, when it doesn't, how Kubernetes handles scaling. These lessons were learned through successes and failures, not overnight. Even ChatGPT and modern ML systems learned scaling lessons from these earlier failures.
4.5.2 Definition and Role
Quality Attribute: A measurable or testable property that specifies how well a system meets the needs of stakeholders along a specific dimension of interest. It acts as a qualification of the functional requirements or the overall system.
A quality attribute has no meaning without a functional requirement. If nobody uses a system, availability, scalability, and performance are irrelevant. The functional requirement (e.g., "a user can search for restaurants and place an order") is the core; the quality attribute ("the search results must appear within 2 seconds") qualifies how well that core function must perform.
Professor's Analogy: A shirt has a color. The shirt is the functional entity; the color (cream, blue) is the attribute. Similarly, a food delivery app must order food (functional); how quickly, how reliably, how available are the quality attributes. The shirt exists regardless of its color — but the color matters to the person wearing it. The app works regardless of speed — but speed matters to the user.
4.5.3 Categories of General Quality Attributes
Operational Attributes:
- Availability — How long the system needs to be accessible. AWS typically advertises 99.99% or 99.95% availability (the SLA). No service promises 100%. Availability is the most foundational attribute — the system must be available before it can be reliable.
- Reliability — How consistently the system delivers its intended functionality without failures.
- Performance — Timing. From the end-user perspective, how quickly the system responds.
- Scalability — Whether the system can handle 100 users or 100 million users without degradation.
Professor's Analogy — Availability vs. Reliability: A person claims "I am very fast in math." Asked "what is 10+2?" — answers 12. Asked "what is 1024 × 1024?" — answers 100 (wrong). "I told you I am fast; I didn't tell you I am correct." Fast = available. Correct = reliable. Availability does not guarantee reliability. A system can be up 99.99% of the time (available) but still return wrong answers (unreliable).
Pitfall — Assuming scalability implies performance: Scalability is viewed from the system perspective (can it handle 100 million users?). Performance is viewed from the individual perspective (does this user get a fast response?). A system can be perfectly scalable behind the scenes — distributing load across 100 servers — but an individual user on a slow mobile network may still experience poor performance. Scalability implies availability (a scalable system stays available), but does not imply reliability or individual performance.
Structural and Portability Attributes:
- Portability — How easy it is to move from one platform to another
- Maintainability — How easily the system can be modified, updated, and fixed
- Configurability — How easily the system can be configured for different environments
- Extensibility — How easily new features can be added
Cross-Cutting Attributes:
- Security — Protection against unauthorized access. Critically important for ML and non-ML systems alike. Security encompasses data security, model security, image security (e.g., Docker image vulnerability scanning), and phishing protection. Different domains (banking, healthcare) will have specific security sub-requirements.
- Usability — How easy it is for users to learn and use the system. Google's success is partly due to a single text box — simplicity. ChatGPT follows the same principle. Overloading an interface with tabs reduces usability.
- Accessibility — How usable the system is for people with disabilities (blindness, hearing disability, speaking disability). A system may perform well but still be inaccessible.
- Legal — Compliance with legal constraints and regulations.
- Interoperability — The ability to integrate with external systems. For a food delivery app, this means integrating with Google Maps APIs, Razor Pay, Stripe, etc., with a target like "99% successful integration transactions."
4.5.4 Quality Attributes with Accepted Measures — Food Delivery Example
Worked Example — Quality Attributes for a Food Delivery App (Swiggy/Zomato):
| Quality Attribute | Measurable Target |
|---|---|
| Performance | Restaurant menu loads within 2 seconds; order placement completes within 3 seconds for 95% of requests |
| Availability | System available 99.95% of the time |
| Usability | At least 90% of users place an order without assistance |
| Scalability | Handle up to 10 million order requests per second during peak traffic without response time degradation beyond 5 seconds |
| Interoperability | 99% successful integration transactions with payment gateways and map APIs |
| Reliability | 99.9% order accuracy — a user who orders masala dosa should receive masala dosa, not anything else |
Sense-check: Each quality attribute has a specific, measurable target. Without the number, the attribute is a wish; with the number, it is a requirement that can be tested and enforced.
Q: Why is consistency not listed as a quality attribute? For example, when a payment happens, all downstream systems should have the same data available. If multiple payments are attempted, the data across services must be consistent.
A: Consistency can absolutely be a very important quality attribute. The list shown is not comprehensive — you can and should add attributes that matter for your specific domain. The professor's point is that the categories are a starting framework, not an exhaustive checklist.
4.5.5 Domain-Specific Priority Exercise
When students mapped top-3 quality attributes for their own workplace applications, the variety illustrated how domain context drives priorities:
| Domain | Top-3 Quality Attributes |
|---|---|
| Banking | Security, Performance, Reliability |
| Public transport | Availability, Reliability |
| Automotive systems | Performance, Security, Availability |
| Medical equipment | Usability, Safety, Reliability |
| Computational mechanics | Accuracy, Performance, Usability |
| Supply chain | Availability, Performance, Reliability |
| Telecom | Performance, Scalability, Security |
| Cloud data | Availability, Scalability, Accuracy |
Recap: Quality attributes are measurable properties that qualify how well a system performs its function. They are meaningless without functional requirements (the shirt must exist before its color matters). The main categories are operational (availability, reliability, performance, scalability), structural (portability, maintainability), and cross-cutting (security, usability, accessibility). Different domains prioritize different attributes — there is no universal ranking. The Flipkart failure and Hotstar success demonstrate that identifying and designing for quality attributes is what separates a system that works from one that collapses under real-world conditions.
4.6 Quality Attributes for ML Systems
4.6.1 ML-Specific Attributes
Hook: A traditional software system either works or it does not — the calculator always gives the right answer. But an ML model? It might be right 92% of the time and wrong 8% of the time. And next month, when the data changes, it might be right only 70% of the time. This unpredictability introduces a whole new set of quality concerns that traditional software engineering never had to face.
Some quality attributes are common across ML and non-ML systems (performance, availability, usability). Others are uniquely important for ML. The professor marks these in red in the slides to distinguish them from general attributes.
Accuracy — How accurately the ML model predicts. In traditional software, this does not apply — a calculation either produces the expected output or it doesn't. In ML, prediction quality exists on a spectrum.
Q: Why is accuracy considered a quality attribute rather than a functional requirement?
A: The functionality is making a prediction. Take a Pima Indians Diabetes dataset: the function is to predict whether a patient is diabetic. The system could deploy with 56% accuracy and still be functional — it takes input, produces output. Accuracy is what qualifies that functionality: "56% is not acceptable; I want above 90%." It is an additional quality dimension layered on top of the core function. Just as the Flipkart app was functional in 2014 but collapsed under load because scalability (a quality attribute) was not considered, an ML model can be functional at any accuracy level — accuracy sets the quality bar.
Scalability (ML-specific nuance) — In non-ML applications, scalability is about handling user requests. In ML systems, there is an additional dimension: data volume scalability. Data generation is massive — every 60 seconds, speech, text, and images are generated at enormous scale. The system must scale to ingest, process, and train on growing data. Additionally, AI workloads (prediction models, RAG applications running on cloud or on-premises) must scale efficiently.
Reliability — How consistently the ML system performs under different operating conditions. Similar to the general concept, but in ML, operating conditions include changing data distributions.
Explainability — This is specific to ML. In traditional software engineering, you do not need to explain why a function returned a particular value. In ML, because of the nature of certain algorithms (neural networks as black boxes), stakeholders — especially humans — need to understand why a model made a particular decision or prediction.
Intuition — When explainability matters: Explainability matters when humans are in the loop — a loan officer needs to understand why an application was rejected, a doctor needs to understand why a diagnosis was flagged. In system-to-system communication (e.g., two agents talking to each other), explainability may not be needed because each system has its own mechanisms. Explainability is a full sub-discipline (referenced as covered in the FATIMA course).
Q: When we consider quality attributes for ML, do they change depending on the sector? For banking, phishing protection should be there.
A: Correct. At the high level, we say "security," but every domain drills down into specific security sub-types — data security, model security, even Docker image security (vulnerability scanning). The same attribute name means different detailed requirements in different domains.
Robustness — The system's ability to maintain performance despite noisy, incomplete, or adversarial inputs. Robustness is more important in ML than in non-ML because in ML the data keeps changing. In traditional software, the same input always produces the same output. In ML, the model must continuously adapt to shifting data.
Worked Examples — Robustness in Practice:
Fraud detection: A rule written five years ago ("flag transactions above ₹50,000 per month for this customer") becomes useless as customer transaction patterns change. The model must evolve with the data, handling noise and incompleteness.
Self-driving car vision: On a perfect sunny day, lane detection and object recognition work flawlessly. On a foggy New Delhi winter day, with heavy rain or poor lighting — will the system still perform? Robustness is about functioning under challenging conditions. The question is whether adequate pre-processing (noise filters, fog mitigation for vision algorithms) is in place to handle these adversities.
Speech recognition: The system should work reasonably well despite background noise — whether through noise filtering or robust model architecture.
Sense-check: Robustness is not about handling the easy cases — it is about not failing catastrophically when conditions deviate from the training environment.
Maintainability — Same concept as traditional software, but ML systems inherit proven architectural patterns from software engineering. Microservices, event-driven architecture, pipe and filter, CQRS — all these established patterns are reused in ML system design. For example, a RAG model is essentially a pipe-and-filter pattern combined with CQRS (Command Query Responsibility Segregation). These are patterns that have been proven in software engineering over decades, now applied to ML. Maintainability in ML means: can you modify, extend, and update the ML pipeline as easily as you would a well-architected software system?
Security and Privacy — Important for both ML and non-ML, but ML introduces unique concerns: sensitive training data (banking, healthcare), model inversion attacks (extracting training data from the model), and adversarial inputs designed to fool models.
Fairness — An ML-specific attribute. It is the principle that the model produces unbiased outcomes across different user groups or demographics. Fairness matters because ML systems are trained on data, and data carries historical bias.
Bias is the inability to learn the true pattern — or the systematic favoring of one outcome over another based on irrelevant characteristics.
Worked Example — Fairness Failure (Amazon 2013):
In 2013, Amazon automated its resume screening process. Because the training data consisted mostly of male applicants historically, the model learned to reject female applicants — penalizing any resume with indicators of being female (such as attending a women's college or being captain of a women's sports team).
Root cause: The model was not programmed to be biased; the training data embedded historical hiring biases, and the model faithfully learned them. The data reflected a decade of hiring patterns where men were disproportionately hired — the model simply codified the status quo.
Sense-check: This is why fairness is a quality attribute, not just an ethical concern. A model that discriminates is not just unfair — it is also likely making systematically wrong predictions for an entire demographic.
The terms bias and variance are well-known in ML: underfitting corresponds to high bias (the model cannot capture the pattern), and overfitting corresponds to high variance (the model captures noise). Fairness is a related but distinct concern: it asks whether the model's errors are disproportionately distributed across demographic groups.
Data Drift — The ability of the system to adapt to changes in the input data distribution over time. Because data in production environments changes continuously, what the model was trained on may no longer represent what it encounters.
Model Drift — The degradation of model performance over time as the relationship between inputs and outputs shifts. Even if the data distribution doesn't change, the underlying phenomenon being modeled may evolve. A model deployed in production cannot be left unchanged indefinitely; it must be monitored and retrained.
Worked Example — COVID Model Drift:
After the first COVID wave (September 2021), a model was trained on 1,200 labeled patient records to classify outcomes as "recovered" or "expired." Random forest achieved 92% accuracy and was deployed.
When COVID Wave 2 arrived (with viral mutations), the model's accuracy dropped significantly on new patient data because:
- A new output class — "shifted" (patient moved to another facility due to ventilator shortages) — had to be introduced
- Feature importance changed (whether REMDESIVIR was administered became critical in Wave 2)
- The target distribution shifted (more patients were being "shifted" as hospitals filled up)
Result: The data structure, feature importance, and target distribution all changed. The model had to be upgraded — model drift had occurred, necessitated largely by data drift.
Sense-check: A model trained on Wave 1 data was a snapshot of that moment. When the world changed, the model became stale. This is why monitoring and retraining are not optional — they are quality requirements.
Q: How will we predict when it's time to revisit the model? What is the lifespan of a deployed model?
A: Monitoring and observability become very important. A continuous feed of ground truth data runs in parallel with the production ML model. The same client data that enters the ML model for prediction also goes to a ground truth pipeline where data scientists and ML engineers analyze whether the underlying patterns are changing. If ground truth data diverges from the assumptions baked into the deployed model, the model must be retrained or replaced. The ground truth data is the feedback loop — nobody can directly inspect the production model, but by analyzing the ground truth, data scientists detect when the model needs updating.
Worked Example — Ground Truth Monitoring (Z5 OTT Platform):
When Z5 released subtitle features (around 2020–2022), the recommendation model had to adapt. People watching Kannada movies might predominantly watch Tamil-dubbed content, but new, highly acclaimed Malayalam movies could shift viewing behavior for the same demographic.
Continuous monitoring of ground truth — what are people actually watching? — reveals when recommendation models need updating. Nobody can simply inspect the deployed ML model directly; ground truth data is the feedback loop that triggers model updates.
Sense-check: The model does not know the world has changed. Only by comparing its predictions against reality (ground truth) can you detect that it needs updating.
Reproducibility — Using the same training process should consistently produce the same results under ideal conditions. This matters for ML because of the stochastic nature of training (random initialization, data shuffling), and is also relevant for non-ML systems.
4.6.2 Summary Distinction
ML-Specific vs. General Quality Attributes:
| ML-Specific (Red) | General (Both ML and Non-ML) |
|---|---|
| Accuracy | Performance |
| Explainability | Availability |
| Robustness | Usability |
| Fairness | Scalability |
| Data Drift | Reliability |
| Model Drift | Maintainability |
| Reproducibility (partially) | Security, Privacy |
| Interoperability, Portability | |
| Configurability, Extensibility |
Pitfall — Treating ML-specific attributes as optional: In traditional software, you can ship a system without worrying about data drift or fairness. In ML, these are not nice-to-haves — they are fundamental quality requirements. A model that degrades silently (data drift) or discriminates (fairness) is a liability, not an asset.
Recap: ML systems inherit all general quality attributes (performance, availability, security, etc.) and add a new layer: accuracy, explainability, robustness, fairness, data drift, model drift, and reproducibility. These ML-specific attributes exist because ML models are probabilistic, data-dependent, and prone to degradation over time. Ground truth monitoring is the feedback loop that detects when a model needs updating — without it, model drift goes undetected until users notice.
4.7 Software Architecture and System Architecture
4.7.1 Software Architecture — The Enduring Definition
Hook: The IEEE definition of software architecture was written over five decades ago — before the internet, before cloud computing, before machine learning. Yet it still holds today. What definition can survive that kind of technological change?
The definition of software architecture — from the IEEE standard — has remained valid for over five decades:
"The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them."
Three components of the IEEE definition:
- Software elements (components) — the building blocks of the system (e.g., a microservice, a database, an ML model)
- Externally visible properties — what each element does, its interface, its behavior (e.g., an API contract, input/output types)
- Relationships among them — how elements connect and communicate (e.g., synchronous calls, message queues, shared databases)
This definition holds for monolith architecture (1970s), client-server architecture, broker architecture, microservices architecture, event-driven architecture — whatever architecture was invented, the definition describes it. The professor emphasizes this universality: in microservices, each microservice is a software element; its property is its API; the relationship might be synchronous (direct call) or asynchronous (message queue). The definition does not constrain how elements connect or what they look like — it only specifies that an architecture is defined by its elements, their properties, and their relationships.
Intuition: Think of the IEEE definition as a grammar for describing any system, regardless of the technology. Just as the grammar of English ("subject-verb-object") works whether you are writing a text message or a novel, the IEEE definition works whether you are describing a 1970s mainframe or a 2025 cloud-native ML pipeline. The grammar does not change; the vocabulary does.
4.7.2 System Architecture
System architecture expands beyond just software to include hardware, ML infrastructure, communication mechanisms, and all other components of a system. Since this course applies software engineering architectural design practices to AI/ML, the term "system architecture" is more appropriate — the architecture is never purely software; it always involves data pipelines, model components, hardware accelerators, and communication channels.
Worked Example — Smart Healthcare System:
A system architecture for continuous patient monitoring:
| Component | Type | Details |
|---|---|---|
| Wearable device | Hardware | Sensors capture SPO2, heart rate on a second-by-second basis |
| Bluetooth/Wi-Fi | Communication | Wearable transmits data to smartphone |
| Mobile app | Software | Forwards data to the cloud |
| Cloud analytics | ML + Infrastructure | Descriptive, diagnostic, predictive analytics |
| Prediction model | ML | Detects bipolar disorder risk (perhaps as a Lambda function) |
| Notification service | Software | Sends alerts to caregivers via synchronous communication |
This is a system architecture: it involves hardware (wearable), software (mobile app), ML component (prediction model in the cloud), infrastructure (cloud), and communication (Bluetooth, Wi-Fi, cloud notifications). No single diagram captures everything — different views show different aspects.
Worked Example — Autonomous Vehicle (Apollo):
| Component | Type |
|---|---|
| Cameras, LIDAR, radar | Hardware sensors |
| Pre-processing modules | Software |
| Perception modules | Software |
| Object detection, lane tracking, path planning | Multiple ML model components |
This system has dozens of ML models that must work on onboard computers in real-time. Mistakes can be fatal, so non-ML components provide significant safety logic, interacting closely with the ML components.
Worked Example — RAG-Based Enterprise Chatbot (Catch-All Architecture):
| Component | Type |
|---|---|
| Cloud server | Hardware/Infrastructure |
| Authentication service, API gateway | Software |
| Embedding model, retriever, LLM, re-ranking | ML |
| Vector database, document store, logging database | Data |
| Docker, Kubernetes, CI/CD pipeline | Deployment |
In practice, a subset of these components would be used — the diagram shows the full range of possible elements for a RAG system.
4.7.3 Requirements Drive Architecture
The fundamental insight of software architecture: Functional requirements and quality requirements are the two inputs to system architecture. A system architect takes both and designs the architecture accordingly. Quality requirements, in a meaningful sense, drive the architecture — they determine which architectural decisions are non-negotiable.
Intuition: Requirements are the blueprint's specifications; architecture is the building. You do not start building and then ask "what should this look like?" — you start with what the building must do (hold 100 families, withstand earthquakes, have natural light) and then design the structure accordingly. The quality requirements (withstand earthquakes) drive the architectural decisions (reinforced steel frame, deep foundations).
An architecturally significant requirement (ASR) is a requirement — functional or quality — that has a measurable impact on the architecture. Not every requirement is architecturally significant. From potentially dozens of functional and quality requirements, the architect identifies the top three or four that will shape the architecture. This prioritization is essential because cost and complexity constraints prevent incorporating everything at the architectural level.
Pitfall — Treating all requirements as architecturally significant: If you try to optimize for everything (scalability, performance, security, cost, time-to-market), you optimize for nothing. The architect's job is to identify the few requirements that will most shape the system — the ASRs — and design around those. The rest are addressed at the component level, not the architectural level.
Recap: Software architecture is defined by three things: elements, their properties, and their relationships. System architecture expands this to include hardware, ML infrastructure, and communication. Requirements — especially quality requirements — drive architectural decisions. The architect identifies a small number of architecturally significant requirements (ASRs) and designs around those, because you cannot optimize for everything simultaneously.
4.8 Architectural and Design Patterns
4.8.1 What Is a Pattern?
Hook: Every Saturday at 10:30 AM, this class meets. No one sends an email at 10:25 AM saying "class starts in 5 minutes." The schedule is a pattern — a proven solution to the recurring problem of "how do we coordinate 60 students across different cities?"
A pattern is a solution to a recurring problem in a given context. The same concept applies across architecture, design, and even non-engineering domains.
Worked Example — Pattern in Everyday Life (MTech AIML Scheduling):
- Context: The MTech AIML program exists, students are enrolled, multiple courses run simultaneously
- Problem: How to schedule classes so that all students can attend without conflicts
- Ad-hoc solution: "I'll email you at 8:25 AM that class starts at 8:30 AM" — this does not work at scale
- Pattern-based solution: A timetable — a fixed schedule (every Saturday, 10:30 AM–12:30 PM for this course) that recurs predictably
Context + Problem + Solution = Pattern. The timetable is a pattern because it solves a recurring scheduling problem in a predictable, reusable way.
In software, architects and designers have spent decades identifying best practices, capturing them as patterns, and publishing them. When a developer faces a problem in a similar context, instead of reinventing the solution, they consult existing patterns. The pattern provides a proven, reusable solution.
Architectural Pattern vs. Design Pattern:
| Type | Scope | Analogy |
|---|---|---|
| Architectural pattern | System-wide level (how components are organized and connected) | How many floors and rooms a building has (three floors, 3 BHK) |
| Design pattern | Component level (how individual classes, objects, or modules are structured) | What flooring and wall color goes into each room on each floor |
Architecture is broader and higher-level; design is more granular. You do not pick the wall color before deciding how many floors the building has.
4.8.2 Architectural Patterns Applicable to ML Systems
The following patterns originate in software engineering but apply to ML system design. Most modern ML systems — whether predictive, generative, or agentic — use one or more of these:
| Pattern | Description | ML Example |
|---|---|---|
| Pipe and Filter | Data flows through sequential processing stages (pipes), each performing a specific transformation (filter). The output of one becomes the input of the next. | Data ingestion → cleaning → feature extraction → model inference → post-processing |
| CQRS (Command Query Responsibility Segregation) | Separates read operations from write operations, often using different data stores optimized for each. | RAG system: write path (ingest, chunk, embed documents) vs. read path (query, retrieve, generate) |
| RAG (Retrieval Augmented Generation) | Essentially a Pipe-and-Filter + CQRS hybrid. Documents are chunked → embedded → stored in a vector database → retrieved → re-ranked → fed to an LLM for generation. | Enterprise chatbot that retrieves relevant documents before generating answers |
| Event-Driven Architecture | Components communicate by publishing and consuming events through a message broker. | IoT sensor data triggers model retraining when drift is detected |
| Broker Pattern | A central broker mediates communication between components (e.g., Kafka as a message queue between IoT sensors and cloud consumers). | Kafka streaming data from multiple sensors to a central ML pipeline |
| Monolithic | All functionality in a single deployable unit. Still popular; there are many ML use cases that use monolithic architecture. | A single Flask/FastAPI app serving a prediction model |
| Microservices | Functionality split into independently deployable services. | Separate services for data preprocessing, model inference, monitoring, and retraining |
| Layered Architecture | System organized into layers (presentation, business logic, data), each building on the layer below. | Traditional ML app: UI → API → model → data layer |
The 70-30 Rule for CQRS: In social media platforms like Instagram and Facebook, 70-80% of traffic is browsing (reading) and only 20-30% is posting (writing). This asymmetry is what makes CQRS particularly effective: the read path is scaled more aggressively than the write path because it handles the majority of traffic. Flipkart's migration to CQRS (separating their read and write data stores) was a major enabler of their post-2014 success.
Intuition — RAG as a combination of proven patterns: RAG is not a fundamentally new invention — it is the combination of two established software engineering patterns: Pipe and Filter (sequential data processing) and CQRS (separate read/write paths). Understanding the underlying patterns helps you reason about RAG systems: you can optimize the write path (ingestion, embedding) independently from the read path (retrieval, generation), and you can add or remove filters (re-ranking, query expansion) without changing the rest of the pipeline.
4.8.3 Student Questions and Answers
Q: CQRS is predominantly used in microservices-based architecture. How does it fit into ML?
A: CQRS is one of the most powerful patterns because most systems naturally have asymmetric read/write loads. In ML, a RAG system separates the "write" path (ingesting and indexing documents) from the "read" path (querying and generating responses). The same principle applies: scale each path independently based on its workload. This will be explored in detail in the next sessions.
Q: How do architects prioritize quality attributes during design? How do you balance scalability, reusability, security, etc.?
A: This is where architecturally significant requirements (ASRs) come in. From all the functional and quality requirements identified, classify a sub-set that is truly significant for the architecture. You cannot incorporate everything — cost and complexity force prioritization. Identify the top three or four quality attributes that must be addressed at the architectural level, and design around those. Material on ASRs can be shared for deeper study.
Q: Is the monolithic pattern still relevant?
A: Monolithic is still widely used. Amazon Prime — after seven to eight years on microservices — moved back to a monolithic architecture. Meanwhile, Netflix continues on microservices. There is no universal answer; it is a trade-off. What works depends on the requirements. The same is true for ML systems: knowing the trade-off points is more important than dogmatically following one pattern. Everything flows from requirements — you don't pick an architecture because it's popular; you pick it because it suits the purpose.
Q: RAG is often called obsolete these days. How do you take that in terms of modern trends?
A: "Obsolete" may not be the right word; "optional" is closer. There are many good alternatives — agentic RAG is becoming quite popular, and graph RAG is another variant. The core pattern (pipe and filter + CQRS) remains valid; the specific implementation choices evolve. The field changes rapidly, but the underlying architectural principles persist.
Q: As we cover these concepts, can you give an illustration of how a pattern would look? It would help with visualization.
A: In the next sessions, we will work through practical examples and in-class demos showing how these patterns are implemented in real ML systems. By the seventh session, after covering the architectural and design patterns, the bigger picture will be clear.
Pitfall — Picking an architecture because it is popular: The professor's key message: "Everything flows from requirements — you don't pick an architecture because it's popular; you pick it because it suits the purpose." Microservices are trendy, but Amazon Prime moved back to monolith. The right architecture is the one that meets your ASRs, not the one that sounds impressive in a presentation.
Recap: A pattern is a proven solution to a recurring problem in a given context. Architectural patterns apply at the system level (microservices, CQRS, pipe and filter); design patterns apply at the component level (observer, singleton). Most ML systems use combinations of these patterns — RAG is essentially pipe-and-filter plus CQRS. The right architecture depends on requirements, not trends. Monolith vs. microservices is a trade-off, not a moral choice.
4.9 Exam Guidance Summary
4.9.1 Examination Format and Assignment Notes
Exam note: The examination will be scenario-based — there will be no "explain" or "define" questions. Every question will present a real-world scenario and ask you to apply concepts. This means rote memorization of definitions is not sufficient; you must be able to look at a system description and identify the relevant quality attributes, architectural patterns, and GR for ML views.
- A preview of question patterns will be provided around the seventh or eighth session (currently at session four, so roughly three more sessions of content before exam guidance).
- Assignment 1 will cover requirements (the GR for ML framework — business view, analytics design view, data preparation view) combined with quality attributes and system architecture. It is a group assignment. The assignment will ask you to map a given use case onto these views.
- Students are encouraged to explore the framework beyond what was covered — the basic concepts are provided, but the assignment expects deeper investigation and application.
- Practice sets/sample questions will be shared later (the course is new, so sample question creation is ongoing).
How to prepare for the scenario-based exam:
- Practice mapping real-world systems onto the three GR for ML views (business, analytics design, data preparation)
- For any given system, identify the top 3-4 quality attributes that would be architecturally significant
- Be able to explain why a particular architectural pattern (monolith vs. microservices, CQRS, etc.) fits a given scenario
- Understand the trade-offs — there is rarely one right answer; the exam rewards reasoning, not recall
4.10 Key Industry Applications and Real-World References
4.10.1 Consolidated References
Case studies:
| Company/Event | Year | Key Lesson |
|---|---|---|
| Flipkart Big Billion Day | 2014 | Monolithic architecture failure under load; migrated to microservices + CQRS |
| Hotstar ICC Cricket World Cup | 2019 | 25.3M concurrent users on AWS; tsunami testing; selective microservice scaling |
| Amazon automated hiring | 2013 | Bias in ML training data favoring male demographics; fairness as a quality attribute |
| Amazon Prime | Recent | Migrated from microservices back to monolith — architecture depends on requirements |
| Netflix | Ongoing | Continues on microservices architecture — different requirements, different choice |
| Z5 OTT platform | 2020-2022 | Subtitle recommendation model drift; ground truth monitoring as feedback loop |
Companies and products: Flipkart, Hotstar, Amazon, Netflix, Swiggy, Zomato, Ola, Uber, Instagram, Facebook, ChatGPT, Apollo (autonomous driving)
Platforms and tools: AWS, Microsoft Azure, Docker, Kubernetes, Kafka, Razor Pay, Stripe, Google Maps API, MongoDB
Algorithms and techniques: SVM, Naive Bayes, Random Forest, Decision Trees, Neural Networks, PCA (Principal Component Analysis), One-hot encoding, Label encoding
Architectural and design patterns: Pipe and Filter, CQRS, RAG, Event-Driven, Broker, Monolithic, Microservices, Layered Architecture, Observer, Singleton
Concepts: GR for ML, UML, bias/variance, ground truth data, observability/monitoring, data drift, model drift, architecturally significant requirements (ASR), tsunami testing
References: Hotstar architect YouTube presentation (~45 minutes, shared with class), FATIMA course (Explainability in ML)
SEML Lecture 4 Notes · GR for ML, Quality Attributes, and System Architecture
Sections Breakdown
Multi-view modelling notation for ML requirements engineering, analogous to UML
Analytics goal, algorithms, indicators, soft goals, and threshold-based algorithm selection
Data cleaning, reduction, and pre-processing for ML pipelines
Operationalizing goals into metrics, accuracy vs precision in ML and measurement theory
Flipkart failure and Hotstar success, categories of quality attributes, measurable targets
ML-specific attributes: accuracy, explainability, robustness, fairness, data drift, model drift
IEEE definition, system architecture components, ASRs driving architectural decisions
Patterns for ML systems: Pipe and Filter, CQRS, RAG, Event-Driven, Microservices, Monolithic
Scenario-based exam format, assignment 1 coverage, preparation strategy
Consolidated case studies, companies, platforms, algorithms, and patterns reference
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
4.1 Review and GR for ML Framework
Must-know: GR for ML is a multi-view notation (business, analytics design, data preparation) that provides unambiguous shared vocabulary for ML requirements engineering, analogous to UML for traditional software.
Top pitfall: Confusing the different views — each view captures a distinct aspect (goals vs. analytics vs. data preparation) and should not be mixed.
Self-check: What are the three main views in the GR for ML framework?
Connects to: 4.2, 4.3
4.2 Analytics Design View
Must-know: The analytics design view specifies the analytics goal, candidate algorithms, evaluation indicators (accuracy, precision, recall, F1), and soft goals. Algorithm selection is a threshold-based filtering process, not a ranking.
Top pitfall: Confusing "algorithm" in the analytics design view (classification/regression techniques) with "algorithm" in the data preparation view (pre-processing techniques).
Self-check: What four elements does the analytics design view capture?
Connects to: 4.1, 4.3, 4.4, 4.5
4.3 Data Preparation View
Must-know: The data preparation view has two sub-tasks: data cleaning and data reduction. It uses mechanisms and pre-processing algorithms (not classification algorithms). The framework supports both top-down and bottom-up approaches.
Top pitfall: Confusing pre-processing algorithms (normalization, encoding) in the data preparation view with classification algorithms (SVM, Naive Bayes) in the analytics design view.
Self-check: What are the two sub-tasks of the data preparation view?
Connects to: 4.1, 4.2
4.4 Measures, Metrics, Accuracy, and Precision
Must-know: Accuracy = correct predictions / total predictions. Precision = true positives / predicted positives. High accuracy can hide poor performance on minority classes. Metrics must be related to the goal, quantifiable, and practical to collect.
Top pitfall: Conflating accuracy with precision. High accuracy on imbalanced datasets can mask poor precision on the minority class.
Self-check: What is the difference between accuracy and precision in ML?
Connects to: 4.2, 4.5, 4.6
4.5 Quality Attributes — General
Must-know: Quality attributes qualify functional requirements. Main categories: operational (availability, reliability, performance, scalability), structural (portability, maintainability), cross-cutting (security, usability). Availability is not reliability. Scalability is not performance. Domain context drives which attributes matter most.
Top pitfall: Assuming availability guarantees reliability, or that scalability implies individual performance. A system can be available but unreliable, or scalable but slow for individual users.
Self-check: What is the difference between availability and reliability?
Connects to: 4.4, 4.6, 4.7
4.6 Quality Attributes for ML Systems
Must-know: ML-specific quality attributes: accuracy, explainability, robustness, fairness, data drift, model drift, reproducibility. Accuracy is a quality attribute (not functional) because it qualifies the prediction function. Ground truth monitoring detects model drift.
Top pitfall: Treating ML-specific attributes (fairness, drift, explainability) as optional. A model that degrades silently or discriminates is a liability.
Self-check: Name three quality attributes that are specific to ML systems.
Connects to: 4.4, 4.5, 4.7
4.7 Software Architecture and System Architecture
Must-know: Software architecture = elements + properties + relationships (IEEE). System architecture includes hardware and ML infrastructure. ASRs (architecturally significant requirements) are the few requirements that drive architectural decisions.
Top pitfall: Treating all requirements as architecturally significant. The architect must identify the top 3-4 ASRs and design around those.
Self-check: What are the three components of the IEEE definition of software architecture?
Connects to: 4.5, 4.6, 4.8
4.8 Architectural and Design Patterns
Must-know: Pattern = context + problem + solution. Key ML patterns: Pipe and Filter, CQRS (separate read/write), RAG (Pipe-and-Filter + CQRS), Event-Driven, Monolithic, Microservices. Architecture depends on requirements, not popularity.
Top pitfall: Picking microservices because they are trendy. Amazon Prime moved back to monolith. The right architecture depends on ASRs.
Self-check: What two software engineering patterns combine to form RAG?
Connects to: 4.7, 4.5
4.9 Exam Guidance Summary
Must-know: Exam is scenario-based: map real systems to GR for ML views, identify ASRs, explain architectural pattern choices with trade-off reasoning.
Top pitfall: Rote memorization of definitions. The exam tests application, not recall.
Self-check: What type of questions will the exam contain?
Connects to: 4.2, 4.3, 4.5, 4.7, 4.8
4.10 Key Industry Applications and Real-World References
Must-know: Key case studies: Flipkart 2014 (monolith failure), Hotstar 2019 (25.3M concurrent, tsunami testing), Amazon hiring bias (fairness), COVID model drift (data/model drift).
Top pitfall: Not connecting case studies to the concepts they illustrate. Each case study maps to specific quality attributes.
Self-check: Which case study illustrates the consequences of not addressing scalability as a quality attribute?
Connects to: 4.5, 4.6, 4.8
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.