A use case describes how a user, stakeholder, or application uses a system to achieve a goal. It turns customer needs into system goals and requirements, providing a practical starting point when the right design direction is unclear. section 1.2.4 section 2.2.2
Derive a system design by asking how each participant will use it:
- Identify users and stakeholders, including data engineers, data scientists, product managers, software engineers, researchers, and security teams. section 1.2.4
- Capture the goals and constraints attached to each interaction, such as data collection, labeling, evaluation, latency, security, and capacity. section 1.2.4
- Design from the outside in: establish user value and interactions before choosing internal logic, storage, or technology. section 2.2.2
- Use concrete scenarios to limit scope and select the simplest architecture that meets immediate production needs. section 6.3
Dataset management service
A data engineer continuously collects and labels training data, then uses ingestion APIs to create datasets, append records, and query status. A data scientist fetches the training dataset through a separate API before training an intent-classification model. These interactions lead to a service with ingestion, internal storage, and dataset-fetching components. section 2.2.2
For model serving, use cases determine how the design evolves from simple to complex scenarios. Avoid an omnipotent system; build only what moves the required models into production while controlling construction and operating costs. section 6.3
Figure 2.6 System overview of the sample dataset management service. The sample service contains three main components, a data ingestion API, internal storage, and a dataset fetching API.
Use the system overview to connect the dataset service’s user interactions with its ingestion API, internal storage, and dataset-fetching API. section 2.2.2
