MLP Portal Full-Stack Design

Design a web portal that gives ML engineers and data scientists one place to record experiments, register models, deploy/promote models, and monitor production model health. Requirements Record experiments with parameters, metrics, artifacts, owner, and lineage. Register models and versions. Deploy a model to an environment and promote it to production. Monitor model quality, data drift, data quality, percent empty, PSI, and alerts. Design REST APIs, database schema, and a UI flow. Be ready for GraphQL and JavaScript / frontend questions. API Sketch POST /experiments GET /experiments/{id} POST /models POST /models/{model_id}/versions POST /deployments POST /deployments/{id}/promote GET /models/{model_id}/monitoring?from=&to= Data Model Experiment(id, owner, project, params_json, metrics_json, artifact_uri, created_at) Model(id, name, owner, task_type, status) ModelVersion(id, model_id, experiment_id, artifact_uri, schema, created_at) Deployment(id, model_version_id, env, status, traffic_percent, created_at) MetricSeries(id, deployment_id, metric_name, timestamp, value, slice_key) AlertRule(id, model_id, metric_name, threshold, window, severity) Notes The portal is not just CRUD. The value is lifecycle state: experiment → model version → staging deployment → production promotion → monitoring and rollback. PSI is a common drift metric: compare distribution buckets between baseline and current data and alert when divergence is large. Time-series query backend matters for monitoring; warehouse tables are fine for offline analysis but too slow for interactive alerts. GraphQL can help UI screens fetch nested experiment / model / deployment views, but REST is simpler for workflow commands. Preparation Draw the main UI screens: experiment list, model detail, deployment history, monitoring dashboard. Prepare schema evolution for model input features. Practice explaining alert routing and rollback when a model underperforms after deployment.