Design Patterns in Machine Learning Code: A Practical Guide with Go Examples

Table of Contents

Design patterns aren’t just academic exercises - they’re communication tools. When you tell someone “this is a factory”, they immediately understand not just the structure, but the intent behind your code. In machine learning and data science workflows, these patterns become even more crucial as we deal with complex data pipelines, model training, and production serving systems.

I’ve been working with ML systems and data engineering for a while now (currently at Semrush, previously at various startups), and these patterns keep popping up in real-world machine learning applications. Most come from the classic Gang of Four book, but they take on interesting shapes in the ML and MLOps world. Let me walk you through what I’ve seen work in production machine learning systems, with practical Go (Golang) examples since that’s what I primarily work with these days for building high-performance ML infrastructure.

Design Patterns in Machine Learning Libraries and Code #

Factory Pattern for Data Loading and Dataset Creation #

The factory pattern decouples objects from how they’re created. This is huge in machine learning pipelines where creating training data loaders can get complex - think distributed systems, different data formats (CSV, Parquet, TFRecord), various preprocessing steps, and data augmentation. A good factory pattern implementation gives data scientists and ML engineers a simple interface while handling all that complexity under the hood.

In Go, we typically define factories through interfaces. Then you implement that interface for your specific use case. Here’s something I’ve used for creating datasets:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76


package ml

import (
    "fmt"
    "math/rand"
)

// Dataset interface - our factory contract
type Dataset interface {
    Len() int
    GetItem(idx int) (Sample, error)
    GetBatch(indices []int) ([]Sample, error)
}

type Sample struct {
    Features []float64
    Label    float64
}

// SequenceDataset for time series data
type SequenceDataset struct {
    sequences [][]float64
    labels    []float64
    windowSize int
}

func NewSequenceDataset(data [][]float64, labels []float64, window int) *SequenceDataset {
    return &SequenceDataset{
        sequences: data,
        labels: labels,
        windowSize: window,
    }
}

func (s *SequenceDataset) Len() int {
    return len(s.sequences)
}

func (s *SequenceDataset) GetItem(idx int) (Sample, error) {
    if idx >= len(s.sequences) {
        return Sample{}, fmt.Errorf("index out of range")
    }
    
    // Add some negative sampling - always makes things interesting
    negSamples := s.getNegativeSamples(idx, 5)
    features := append(s.sequences[idx], negSamples...)
    
    return Sample{
        Features: features,
        Label: s.labels[idx],
    }, nil
}

func (s *SequenceDataset) getNegativeSamples(exclude int, count int) []float64 {
    samples := make([]float64, 0, count)
    for i := 0; i < count; i++ {
        idx := rand.Intn(s.Len())
        if idx == exclude {
            idx = (idx + 1) % s.Len()
        }
        samples = append(samples, s.sequences[idx][0]) // just first element for simplicity
    }
    return samples
}

func (s *SequenceDataset) GetBatch(indices []int) ([]Sample, error) {
    batch := make([]Sample, len(indices))
    for i, idx := range indices {
        sample, err := s.GetItem(idx)
        if err != nil {
            return nil, err
        }
        batch[i] = sample
    }
    return batch, nil
}

This reminds me of PyTorch’s Dataset, but Go’s explicit error handling actually makes it clearer what can go wrong. No silent failures here.

Another neat factory example is for text processing. I worked on a project where we needed to process different document formats:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


// TextCorpus interface for different text sources
type TextCorpus interface {
    GetTexts() <-chan []string
    Len() int
}

type FileCorpus struct {
    filepath string
    stopwords map[string]bool
}

func NewFileCorpus(path string) *FileCorpus {
    stopwords := map[string]bool{
        "the": true, "a": true, "an": true, 
        "and": true, "or": true, "but": true,
    }
    return &FileCorpus{filepath: path, stopwords: stopwords}
}

func (fc *FileCorpus) GetTexts() <-chan []string {
    out := make(chan []string)
    go func() {
        defer close(out)
        // In real code, you'd read from file here
        // Simplified for brevity
        docs := []string{
            "machine learning is fascinating",
            "go makes concurrent processing easy",
        }
        
        for _, doc := range docs {
            words := fc.processDocument(doc)
            out <- words
        }
    }()
    return out
}

func (fc *FileCorpus) processDocument(doc string) []string {
    // Super simple tokenization - real code would use proper NLP
    words := []string{}
    for _, word := range strings.Fields(strings.ToLower(doc)) {
        if !fc.stopwords[word] {
            words = append(words, word)
        }
    }
    return words
}

func (fc *FileCorpus) Len() int {
    // You'd actually count documents here
    return 2
}

Adapter Pattern for Data Ingestion and ETL Pipelines #

The adapter pattern helps when you need to work with incompatible interfaces in your data pipeline. Every machine learning project I’ve worked on needed to read training data from different sources - CSV files, Parquet datasets, JSON APIs, databases, sometimes weird proprietary formats. The adapter pattern makes this data ingestion manageable and scalable.

Go doesn’t have Pandas (sadly), but we can create similar adapters:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102


package dataio

import (
    "encoding/csv"
    "encoding/json"
    "os"
)

// DataFrame is our common data structure
type DataFrame struct {
    Columns []string
    Data    [][]interface{}
}

// Reader interface that all adapters implement
type Reader interface {
    Read(filepath string) (*DataFrame, error)
}

// CSVReader adapter
type CSVReader struct{}

func (r *CSVReader) Read(filepath string) (*DataFrame, error) {
    file, err := os.Open(filepath)
    if err != nil {
        return nil, err
    }
    defer file.Close()
    
    reader := csv.NewReader(file)
    records, err := reader.ReadAll()
    if err != nil {
        return nil, err
    }
    
    df := &DataFrame{
        Columns: records[0],
        Data: make([][]interface{}, len(records)-1),
    }
    
    for i, record := range records[1:] {
        row := make([]interface{}, len(record))
        for j, val := range record {
            row[j] = val
        }
        df.Data[i] = row
    }
    
    return df, nil
}

// JSONReader adapter  
type JSONReader struct{}

func (r *JSONReader) Read(filepath string) (*DataFrame, error) {
    file, err := os.Open(filepath)
    if err != nil {
        return nil, err
    }
    defer file.Close()
    
    var data []map[string]interface{}
    decoder := json.NewDecoder(file)
    if err := decoder.Decode(&data); err != nil {
        return nil, err
    }
    
    // Extract columns from first object
    columns := make([]string, 0)
    if len(data) > 0 {
        for key := range data[0] {
            columns = append(columns, key)
        }
    }
    
    df := &DataFrame{
        Columns: columns,
        Data: make([][]interface{}, len(data)),
    }
    
    for i, row := range data {
        dfRow := make([]interface{}, len(columns))
        for j, col := range columns {
            dfRow[j] = row[col]
        }
        df.Data[i] = dfRow
    }
    
    return df, nil
}

// Factory function to get the right reader
func GetReader(format string) Reader {
    switch format {
    case "csv":
        return &CSVReader{}
    case "json":
        return &JSONReader{}
    default:
        return &CSVReader{} // default to CSV, why not
    }
}

Decorator Pattern for Model Monitoring and Observability #

The decorator pattern (or middleware in Go terms) lets you wrap functionality around existing code for monitoring and observability. In Python ML frameworks you’d use @decorators, in Go we typically wrap functions or use middleware chains. This is essential for production ML systems where you need metrics, logging, and monitoring.

Here’s a timer decorator I use constantly when benchmarking models:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


package utils

import (
    "log"
    "time"
)

// TimedResult wraps a result with timing info
type TimedResult struct {
    Result interface{}
    Duration time.Duration
}

// TimeIt wraps any function to measure execution time
func TimeIt(name string, fn func() interface{}) TimedResult {
    start := time.Now()
    result := fn()
    duration := time.Since(start)
    
    log.Printf("%s took %v", name, duration)
    
    return TimedResult{
        Result: result,
        Duration: duration,
    }
}

// Example: timing model inference
func predictWithTiming(model Model, input []float64) TimedResult {
    return TimeIt("model.Predict", func() interface{} {
        return model.Predict(input)
    })
}

A more sophisticated example - caching decorator for expensive computations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


type CacheFunc func(args ...interface{}) interface{}

func WithCache(fn CacheFunc, cacheSize int) CacheFunc {
    type cacheEntry struct {
        args   []interface{}
        result interface{}
    }
    
    cache := make([]cacheEntry, 0, cacheSize)
    
    return func(args ...interface{}) interface{} {
        // Check cache
        for _, entry := range cache {
            if equalArgs(entry.args, args) {
                log.Println("Cache hit!")
                return entry.result
            }
        }
        
        // Cache miss - compute result
        result := fn(args...)
        
        // Add to cache (simple FIFO, you could do LRU)
        if len(cache) >= cacheSize {
            cache = cache[1:] // Remove oldest
        }
        cache = append(cache, cacheEntry{args: args, result: result})
        
        return result
    }
}

func equalArgs(a, b []interface{}) bool {
    if len(a) != len(b) {
        return false
    }
    // Simplified comparison - real code needs proper equality check
    for i := range a {
        if a[i] != b[i] {
            return false
        }
    }
    return true
}

Strategy Pattern for Algorithm Selection and Hyperparameter Tuning #

The strategy pattern allows switching algorithms and models at runtime. Every machine learning library has this - different optimizers (SGD, Adam, RMSprop), loss functions (MSE, cross-entropy, hinge loss), tree construction methods (CART, ID3, C4.5). Users can plug in their own implementations for custom algorithms and experimentation.

Here’s how you might implement custom objectives in a Go ML library:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


package ml

import "math"

// Objective interface for different loss functions
type Objective interface {
    Loss(predicted, actual []float64) float64
    Gradient(predicted, actual []float64) []float64
}

// MSE - the classic
type MSEObjective struct{}

func (m *MSEObjective) Loss(predicted, actual []float64) float64 {
    sum := 0.0
    for i := range predicted {
        diff := predicted[i] - actual[i]
        sum += diff * diff
    }
    return sum / float64(len(predicted))
}

func (m *MSEObjective) Gradient(predicted, actual []float64) []float64 {
    grad := make([]float64, len(predicted))
    n := float64(len(predicted))
    for i := range predicted {
        grad[i] = 2.0 * (predicted[i] - actual[i]) / n
    }
    return grad
}

// Custom objective - squared log error (why not?)
type SquaredLogError struct{}

func (s *SquaredLogError) Loss(predicted, actual []float64) float64 {
    sum := 0.0
    for i := range predicted {
        // Clip to avoid log of negative
        pred := math.Max(predicted[i], 1e-7)
        act := math.Max(actual[i], 1e-7)
        diff := math.Log(pred) - math.Log(act)
        sum += diff * diff
    }
    return sum / float64(len(predicted))
}

func (s *SquaredLogError) Gradient(predicted, actual []float64) []float64 {
    grad := make([]float64, len(predicted))
    n := float64(len(predicted))
    for i := range predicted {
        pred := math.Max(predicted[i], 1e-7)
        act := math.Max(actual[i], 1e-7)
        grad[i] = 2.0 * (math.Log(pred) - math.Log(act)) / (pred * n)
    }
    return grad
}

// Trainer that accepts any objective
type Trainer struct {
    objective Objective
    learningRate float64
}

func NewTrainer(obj Objective, lr float64) *Trainer {
    return &Trainer{objective: obj, learningRate: lr}
}

func (t *Trainer) Train(model *Model, data Dataset) {
    // Training loop using the strategy
    for i := 0; i < 100; i++ {
        batch, _ := data.GetBatch([]int{0, 1, 2, 3})
        
        predictions := model.Forward(batch)
        loss := t.objective.Loss(predictions, getLabels(batch))
        grad := t.objective.Gradient(predictions, getLabels(batch))
        
        // Update model using gradients
        model.UpdateWeights(grad, t.learningRate)
        
        if i%10 == 0 {
            log.Printf("Iteration %d, loss: %.4f", i, loss)
        }
    }
}

Iterator Pattern for Batch Processing and Data Streaming #

The iterator pattern provides traversal without exposing the underlying data structure. In Go, channels are perfect for this in ML pipelines. They naturally implement iteration patterns for batch processing, mini-batch gradient descent, and streaming data processing.

Here’s a DataLoader that reminds me of PyTorch’s, but with Go’s concurrency:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


package ml

import (
    "math/rand"
    "sync"
)

type DataLoader struct {
    dataset   Dataset
    batchSize int
    shuffle   bool
    workers   int
}

func NewDataLoader(ds Dataset, batchSize int, shuffle bool, workers int) *DataLoader {
    return &DataLoader{
        dataset:   ds,
        batchSize: batchSize,
        shuffle:   shuffle,
        workers:   workers,
    }
}

func (dl *DataLoader) Iterate() <-chan []Sample {
    out := make(chan []Sample)
    
    go func() {
        defer close(out)
        
        indices := make([]int, dl.dataset.Len())
        for i := range indices {
            indices[i] = i
        }
        
        if dl.shuffle {
            rand.Shuffle(len(indices), func(i, j int) {
                indices[i], indices[j] = indices[j], indices[i]
            })
        }
        
        // Process batches in parallel
        var wg sync.WaitGroup
        batchChan := make(chan []int, dl.workers)
        
        // Start workers
        for w := 0; w < dl.workers; w++ {
            wg.Add(1)
            go func() {
                defer wg.Done()
                for batchIndices := range batchChan {
                    batch, err := dl.dataset.GetBatch(batchIndices)
                    if err != nil {
                        log.Printf("Error getting batch: %v", err)
                        continue
                    }
                    out <- batch
                }
            }()
        }
        
        // Send batches to workers
        for i := 0; i < len(indices); i += dl.batchSize {
            end := i + dl.batchSize
            if end > len(indices) {
                end = len(indices)
            }
            batchChan <- indices[i:end]
        }
        
        close(batchChan)
        wg.Wait()
    }()
    
    return out
}

// Usage is clean with range
func train(model *Model, loader *DataLoader) {
    for batch := range loader.Iterate() {
        // Process batch
        loss := model.TrainOnBatch(batch)
        log.Printf("Batch loss: %.4f", loss)
    }
}

Pipeline Pattern for Feature Engineering and Model Training #

The pipeline pattern chains transformations together for end-to-end ML workflows. In scikit-learn you have Pipeline, in Apache Spark MLlib you have ML Pipelines, and in Go we can build something similar for feature engineering and model training. Actually, I find Go’s explicit approach makes pipelines easier to debug - you can see exactly what’s happening at each preprocessing and training step.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90


package pipeline

import "fmt"

// Transform interface for pipeline stages
type Transform interface {
    Fit(data DataFrame) error
    Transform(data DataFrame) (DataFrame, error)
    FitTransform(data DataFrame) (DataFrame, error)
}

// Pipeline chains multiple transforms
type Pipeline struct {
    steps []Transform
    fitted bool
}

func NewPipeline(steps ...Transform) *Pipeline {
    return &Pipeline{steps: steps}
}

func (p *Pipeline) Fit(data DataFrame) error {
    current := data
    for i, step := range p.steps {
        if err := step.Fit(current); err != nil {
            return fmt.Errorf("step %d fit failed: %w", i, err)
        }
        
        // Transform data for next step
        next, err := step.Transform(current)
        if err != nil {
            return fmt.Errorf("step %d transform failed: %w", i, err)
        }
        current = next
    }
    p.fitted = true
    return nil
}

func (p *Pipeline) Transform(data DataFrame) (DataFrame, error) {
    if !p.fitted {
        return DataFrame{}, fmt.Errorf("pipeline not fitted")
    }
    
    current := data
    for i, step := range p.steps {
        next, err := step.Transform(current)
        if err != nil {
            return DataFrame{}, fmt.Errorf("step %d failed: %w", i, err)
        }
        current = next
    }
    return current, nil
}

// Example transforms
type StandardScaler struct {
    means []float64
    stds  []float64
}

func (s *StandardScaler) Fit(data DataFrame) error {
    // Calculate means and stds
    // Simplified - assumes numeric data
    s.means = make([]float64, len(data.Columns))
    s.stds = make([]float64, len(data.Columns))
    
    // ... calculation logic ...
    return nil
}

func (s *StandardScaler) Transform(data DataFrame) (DataFrame, error) {
    // Apply standardization
    result := data // copy in real code
    for i := range result.Data {
        for j := range result.Data[i] {
            if val, ok := result.Data[i][j].(float64); ok {
                result.Data[i][j] = (val - s.means[j]) / s.stds[j]
            }
        }
    }
    return result, nil
}

func (s *StandardScaler) FitTransform(data DataFrame) (DataFrame, error) {
    if err := s.Fit(data); err != nil {
        return DataFrame{}, err
    }
    return s.Transform(data)
}

Design Patterns in Machine Learning Systems and MLOps #

Patterns aren’t just about code structure - they apply to ML system architecture and MLOps too. Let me share what I’ve seen work in production machine learning deployments at scale.

Proxy Pattern for Model Serving and Caching #

The proxy pattern provides a substitute for another service or resource in ML serving infrastructure. This is everywhere in production ML systems - cache proxies for inference results, reverse proxies for load balancing model servers, API gateways for model versioning.

We had this issue at my previous company where 80% of our search queries were the same popular terms. Computing embeddings and running ranking models for these repeatedly was wasteful. Cache proxy to the rescue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


package serving

import (
    "crypto/md5"
    "encoding/hex"
    "sync"
    "time"
)

type ModelServer interface {
    Predict(input []float64) ([]float64, error)
}

type CacheProxy struct {
    backend ModelServer
    cache   map[string]cacheEntry
    mu      sync.RWMutex
    ttl     time.Duration
}

type cacheEntry struct {
    result    []float64
    timestamp time.Time
}

func NewCacheProxy(backend ModelServer, ttl time.Duration) *CacheProxy {
    return &CacheProxy{
        backend: backend,
        cache:   make(map[string]cacheEntry),
        ttl:     ttl,
    }
}

func (c *CacheProxy) Predict(input []float64) ([]float64, error) {
    key := c.hashInput(input)
    
    // Check cache
    c.mu.RLock()
    if entry, ok := c.cache[key]; ok {
        if time.Since(entry.timestamp) < c.ttl {
            c.mu.RUnlock()
            log.Println("Cache hit!")
            return entry.result, nil
        }
    }
    c.mu.RUnlock()
    
    // Cache miss - call backend
    result, err := c.backend.Predict(input)
    if err != nil {
        return nil, err
    }
    
    // Update cache
    c.mu.Lock()
    c.cache[key] = cacheEntry{
        result:    result,
        timestamp: time.Now(),
    }
    c.mu.Unlock()
    
    return result, nil
}

func (c *CacheProxy) hashInput(input []float64) string {
    // Simple hash - in production you'd want something more sophisticated
    h := md5.New()
    for _, v := range input {
        h.Write([]byte(fmt.Sprintf("%f", v)))
    }
    return hex.EncodeToString(h.Sum(nil))
}

For serving models at scale, reverse proxy pattern works great. Though honestly, these days I’d probably just use Kubernetes ingress or a service mesh. But here’s a simple version:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


type ModelReverseProxy struct {
    backends []string
    current  int
    mu       sync.Mutex
}

func NewModelReverseProxy(backends []string) *ModelReverseProxy {
    return &ModelReverseProxy{backends: backends}
}

func (p *ModelReverseProxy) GetBackend() string {
    p.mu.Lock()
    defer p.mu.Unlock()
    
    // Simple round-robin
    backend := p.backends[p.current]
    p.current = (p.current + 1) % len(p.backends)
    return backend
}

func (p *ModelReverseProxy) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    backend := p.GetBackend()
    
    // Forward request to backend
    proxyURL, _ := url.Parse(backend)
    proxy := httputil.NewSingleHostReverseProxy(proxyURL)
    proxy.ServeHTTP(w, r)
}

Mediator Pattern for Multi-Model Orchestration #

The mediator pattern keeps ML services from talking directly to each other. Think of it as a traffic controller for your model ensemble or multi-armed bandit system. Really useful when you have multiple recommendation models, ranking algorithms, or personalization engines competing for user attention.

I remember building something like this for a home page with multiple ML-powered widgets. Each widget thought it was the most important (classic), but we needed to coordinate them:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73


package mediator

type Widget interface {
    GetRecommendations() []Item
    GetPriority() int
    GetMinItems() int
}

type Item struct {
    ID    string
    Score float64
}

type HomePageMediator struct {
    widgets []Widget
    maxSlots int
}

func NewHomePageMediator(maxSlots int) *HomePageMediator {
    return &HomePageMediator{
        maxSlots: maxSlots,
        widgets:  []Widget{},
    }
}

func (m *HomePageMediator) RegisterWidget(w Widget) {
    m.widgets = append(m.widgets, w)
}

func (m *HomePageMediator) AllocateSlots() map[Widget][]Item {
    // Sort widgets by priority
    sort.Slice(m.widgets, func(i, j int) bool {
        return m.widgets[i].GetPriority() > m.widgets[j].GetPriority()
    })
    
    allocation := make(map[Widget][]Item)
    usedSlots := 0
    seenItems := make(map[string]bool)
    
    for _, widget := range m.widgets {
        if usedSlots >= m.maxSlots {
            break
        }
        
        recs := widget.GetRecommendations()
        minItems := widget.GetMinItems()
        
        // Filter out duplicates
        filtered := []Item{}
        for _, item := range recs {
            if !seenItems[item.ID] {
                filtered = append(filtered, item)
                seenItems[item.ID] = true
            }
        }
        
        // Only include widget if we have minimum items
        if len(filtered) >= minItems {
            slotsToUse := min(len(filtered), m.maxSlots-usedSlots)
            allocation[widget] = filtered[:slotsToUse]
            usedSlots += slotsToUse
        }
    }
    
    return allocation
}

func min(a, b int) int {
    if a < b {
        return a
    }
    return b
}

Conclusion: Building Maintainable ML Systems with Design Patterns #

These design patterns keep appearing in machine learning systems because they solve real problems:

Factory pattern helps manage complex dataset and model creation
Adapter pattern enables seamless data ingestion from multiple sources
Decorator pattern adds monitoring and observability to ML pipelines
Strategy pattern makes algorithms and models pluggable and testable
Iterator pattern handles efficient batch processing and data streaming
Pipeline pattern chains feature engineering and model training steps
Proxy pattern optimizes model serving with caching and load balancing
Mediator pattern orchestrates multiple models and recommendation systems

The Go implementations might look different from Python (TensorFlow, PyTorch) or Java (Spark MLlib) versions, but the core design principles remain the same. Actually, I think Go’s explicit nature and built-in concurrency primitives make some patterns even clearer for production ML systems.

These patterns are especially valuable in MLOps and production ML deployments where maintainability, scalability, and monitoring are crucial. Whether you’re building data pipelines, training infrastructure, or model serving systems, these patterns provide tested solutions to common challenges.

What design patterns do you see in your machine learning code? Would love to hear about other patterns that work well in production ML and data science systems.

References #

Design Patterns: Elements of Reusable Object-Oriented Software - The classic Gang of Four book
Head First Design Patterns - More accessible introduction
Refactoring Guru - Great online resource with examples
Original inspiration from Eugene Yan’s excellent post on this topic

This post was inspired by Eugene Yan’s original article on design patterns in ML. I’ve adapted the concepts to Go and added examples from my own experience. All mistakes are mine.