Facade Pattern — Optimization¶

1. How to use this file¶

Twelve scenarios where facade code is slower than it needs to be. Each:

• Scenario — the inefficiency.
• Before — measured-slow code with realistic benchmark numbers.
• After (collapsible) — optimised version with benchmark comparison.
• Why faster — what changed at the runtime level.
• Trade-offs — what you lose by optimising.
• When NOT to do this — the cases where the optimisation isn't worth it.

The honest answer for most facade "optimisations": the facade is rarely the bottleneck — the subsystems behind it are. A facade call itself is 1-10 ns of overhead. What hurts is what the facade does: serial calls when parallel would work, locks that span the whole flow, allocations that fan out into every subsystem method, lazy init via mutex, and so on. Benchmarks below are illustrative. Qualitative direction (allocs vs no allocs, serialised vs parallel) matters more than absolute ns/op. Go 1.22, amd64, GOMAXPROCS=8.

2. Table of Contents¶

1. How to use this file
2. Table of Contents
3. Exercise 1 — Facade lock around all calls instead of per-subsystem locks
4. Exercise 2 — Sequential subsystem calls when they can run in parallel
5. Exercise 3 — Allocation per call for subsystem method args
6. Exercise 4 — Facade returning interface forces escape
7. Exercise 5 — Mutex in facade for simple state instead of atomic
8. Exercise 6 — Lazy init via mutex instead of sync.Once
9. Exercise 7 — Many small subsystem calls instead of batching
10. Exercise 8 — PGO devirtualization for hot facade methods
11. Exercise 9 — fmt.Sprintf in facade error wrapping
12. Exercise 10 — Facade caching subsystem results for read-heavy workloads
13. Exercise 11 — Facade per request instead of reused with injected state
14. Exercise 12 — Reflection-based dispatch replaced by direct method calls
15. When NOT to optimize
16. Summary

Exercise 1 — Facade lock around all calls instead of per-subsystem locks¶

Scenario: An OrderFacade holds a single mutex that's locked for the entire duration of every facade method. The facade calls into independent subsystems (inventory, billing, shipping, notification) that don't share state. Under load, the global lock serializes every request even when subsystems would happily run concurrently.

Before:

type OrderFacade struct {
    mu           sync.Mutex // guards everything
    inventory    *InventoryService
    billing      *BillingService
    shipping     *ShippingService
    notification *NotificationService
}

func (f *OrderFacade) PlaceOrder(ctx context.Context, o Order) error {
    f.mu.Lock()
    defer f.mu.Unlock()

    if err := f.inventory.Reserve(ctx, o.Items); err != nil {
        return err
    }
    if err := f.billing.Charge(ctx, o.UserID, o.Total); err != nil {
        return err
    }
    if err := f.shipping.Schedule(ctx, o.Address); err != nil {
        return err
    }
    return f.notification.Send(ctx, o.UserID)
}

Benchmark with 8 concurrent callers, each subsystem call simulating ~2 ms of work:

BenchmarkGlobalLock-8     500    8_200_000 ns/op    256 B/op    5 allocs/op

The whole flow takes ~8 ms when run sequentially under a global lock. The four subsystems each take ~2 ms; they execute in series because the lock prevents any concurrency.

type OrderFacade struct {
    inventory    *InventoryService    // each is internally safe
    billing      *BillingService
    shipping     *ShippingService
    notification *NotificationService
}

func (f *OrderFacade) PlaceOrder(ctx context.Context, o Order) error {
    if err := f.inventory.Reserve(ctx, o.Items); err != nil {
        return err
    }
    if err := f.billing.Charge(ctx, o.UserID, o.Total); err != nil {
        return err
    }
    if err := f.shipping.Schedule(ctx, o.Address); err != nil {
        return err
    }
    return f.notification.Send(ctx, o.UserID)
}

BenchmarkPerSubsystemLock-8     4000    2_100_000 ns/op    256 B/op    5 allocs/op

# Detect contention on the mutex
go test -bench=. -mutexprofile=mu.pprof -blockprofile=block.pprof
go tool pprof -top mu.pprof    # confirm the facade mutex disappears from contention top
go tool pprof -top block.pprof # confirm blocking time dropped

Exercise 2 — Sequential subsystem calls when they can run in parallel¶

Scenario: A DashboardFacade.Render calls into four read-only subsystems (user profile, recent orders, recommendations, notifications). Each takes ~50 ms because they hit different downstream services. The facade calls them sequentially; the user waits for the sum.

Before:

type DashboardData struct {
    Profile         UserProfile
    Orders          []Order
    Recommendations []Item
    Notifications   []Notification
}

func (f *DashboardFacade) Render(ctx context.Context, userID int64) (DashboardData, error) {
    profile, err := f.users.Get(ctx, userID)       // ~50 ms
    if err != nil {
        return DashboardData{}, err
    }
    orders, err := f.orders.Recent(ctx, userID, 10) // ~50 ms
    if err != nil {
        return DashboardData{}, err
    }
    recs, err := f.recommender.For(ctx, userID)     // ~50 ms
    if err != nil {
        return DashboardData{}, err
    }
    notifs, err := f.notifs.Unread(ctx, userID)     // ~50 ms
    if err != nil {
        return DashboardData{}, err
    }
    return DashboardData{
        Profile: profile, Orders: orders,
        Recommendations: recs, Notifications: notifs,
    }, nil
}

BenchmarkSerialFacade-8     5    200_000_000 ns/op

200 ms per render — four 50 ms calls in series.

import "golang.org/x/sync/errgroup"

func (f *DashboardFacade) Render(ctx context.Context, userID int64) (DashboardData, error) {
    g, gctx := errgroup.WithContext(ctx)

    var (
        profile UserProfile
        orders  []Order
        recs    []Item
        notifs  []Notification
    )

    g.Go(func() error {
        var err error
        profile, err = f.users.Get(gctx, userID)
        return err
    })
    g.Go(func() error {
        var err error
        orders, err = f.orders.Recent(gctx, userID, 10)
        return err
    })
    g.Go(func() error {
        var err error
        recs, err = f.recommender.For(gctx, userID)
        return err
    })
    g.Go(func() error {
        var err error
        notifs, err = f.notifs.Unread(gctx, userID)
        return err
    })

    if err := g.Wait(); err != nil {
        return DashboardData{}, err
    }
    return DashboardData{
        Profile: profile, Orders: orders,
        Recommendations: recs, Notifications: notifs,
    }, nil
}

BenchmarkParallelFacade-8    20    52_000_000 ns/op

# Verify the speedup matches the slowest call, not the sum
go test -bench=Facade -trace=trace.out
go tool trace trace.out   # look at the goroutine timeline

Exercise 3 — Allocation per call for subsystem method args¶

Scenario: A MetricsFacade.Record method builds a request struct on every call, populated with several slices and a map. The subsystem doesn't retain the struct; it reads the fields and writes to a backing store. Yet every call allocates.

Before:

type MetricEvent struct {
    Labels   map[string]string
    Tags     []string
    Values   []float64
    Buckets  []float64
}

type MetricsFacade struct {
    backend *MetricsBackend
}

func (f *MetricsFacade) Record(name string, value float64, tags []string) {
    ev := MetricEvent{
        Labels:  map[string]string{"name": name},
        Tags:    append([]string{}, tags...),
        Values:  []float64{value},
        Buckets: []float64{0.1, 0.5, 1, 5, 10},
    }
    f.backend.Submit(ev)
}

BenchmarkAllocPerRecord-8    2000000    720 ns/op    432 B/op    7 allocs/op

Every call creates a fresh map, three slices, and the struct itself. At 100k RPS, that's ~43 MB/s of allocation pressure, all of it ephemeral.

type metricBuf struct {
    Labels  map[string]string
    Tags    []string
    Values  []float64
    Buckets []float64
}

var metricPool = sync.Pool{
    New: func() any {
        return &metricBuf{
            Labels:  make(map[string]string, 4),
            Tags:    make([]string, 0, 8),
            Values:  make([]float64, 0, 4),
            Buckets: []float64{0.1, 0.5, 1, 5, 10}, // fixed; reused
        }
    },
}

func (f *MetricsFacade) Record(name string, value float64, tags []string) {
    b := metricPool.Get().(*metricBuf)
    defer func() {
        clear(b.Labels)
        b.Tags = b.Tags[:0]
        b.Values = b.Values[:0]
        // Buckets is fixed; do not reset
        metricPool.Put(b)
    }()

    b.Labels["name"] = name
    b.Tags = append(b.Tags, tags...)
    b.Values = append(b.Values, value)

    f.backend.SubmitBuf(b) // backend must NOT retain b after return
}

BenchmarkPooledRecord-8     20000000     85 ns/op     0 B/op    0 allocs/op

# Confirm zero allocs and the alloc rate dropped
go test -bench=Record -benchmem
GODEBUG=gctrace=1 go test -bench=Record -benchtime=10s 2>&1 | head -20

Exercise 4 — Facade returning interface forces escape¶

Scenario: The facade method returns an interface (io.ReadCloser, Result, etc.). The concrete type the facade builds escapes to the heap because the compiler cannot prove the interface doesn't outlive the function.

Before:

type QueryResult interface {
    Next() bool
    Scan(dest ...any) error
    Close() error
}

type DBFacade struct{ pool *sql.DB }

func (f *DBFacade) Query(ctx context.Context, q string) QueryResult {
    rows, _ := f.pool.QueryContext(ctx, q)
    return &queryResultImpl{rows: rows} // escapes
}

type queryResultImpl struct{ rows *sql.Rows }

func (q *queryResultImpl) Next() bool                  { return q.rows.Next() }
func (q *queryResultImpl) Scan(dest ...any) error      { return q.rows.Scan(dest...) }
func (q *queryResultImpl) Close() error                { return q.rows.Close() }

func consume(f *DBFacade) {
    for i := 0; i < 1000; i++ {
        r := f.Query(ctx, "SELECT 1")
        r.Close()
    }
}

BenchmarkInterfaceReturn-8    2000000    520 ns/op    48 B/op    2 allocs/op

Escape analysis confirms (go build -gcflags='-m -m' . 2>&1 | grep queryResultImpl): &queryResultImpl{...} escapes to heap.

func (f *DBFacade) Query(ctx context.Context, q string) *queryResultImpl {
    rows, _ := f.pool.QueryContext(ctx, q)
    return &queryResultImpl{rows: rows}
}

func consume(f *DBFacade) {
    for i := 0; i < 1000; i++ {
        r := f.Query(ctx, "SELECT 1") // *queryResultImpl, may stack-allocate
        r.Close()
    }
}

BenchmarkConcreteReturn-8     20000000     45 ns/op     0 B/op    0 allocs/op

# Confirm the value no longer escapes
go build -gcflags='-m' . 2>&1 | grep queryResultImpl
# Want to see: "does not escape" or "moved to stack"

Exercise 5 — Mutex in facade for simple state instead of atomic¶

Scenario: The facade tracks a single counter (number of operations performed, current generation, last-request timestamp). The counter is read and written under a mutex.

Before:

type Facade struct {
    mu    sync.Mutex
    ops   int64
    last  int64
}

func (f *Facade) Do() {
    f.mu.Lock()
    f.ops++
    f.last = time.Now().UnixNano()
    f.mu.Unlock()
    // ... real work
}

func (f *Facade) Stats() (ops int64, lastNs int64) {
    f.mu.Lock()
    defer f.mu.Unlock()
    return f.ops, f.last
}

BenchmarkMutexCounter-8     50000000     25 ns/op    0 B/op    0 allocs/op

Under contention (8 goroutines), throughput collapses because every goroutine serialises on the lock.

BenchmarkMutexCounterContended-8    5000000    280 ns/op

type Facade struct {
    ops  atomic.Int64
    last atomic.Int64
}

func (f *Facade) Do() {
    f.ops.Add(1)
    f.last.Store(time.Now().UnixNano())
    // ... real work
}

func (f *Facade) Stats() (ops int64, lastNs int64) {
    return f.ops.Load(), f.last.Load()
}

BenchmarkAtomicCounter-8    300000000     4 ns/op    0 B/op    0 allocs/op

BenchmarkAtomicCounterContended-8    150000000     12 ns/op

# Compare lock vs atomic under contention
go test -bench=Counter -cpu=1,2,4,8

Exercise 6 — Lazy init via mutex instead of sync.Once¶

Scenario: The facade lazily initialises an expensive subsystem (TLS-bound HTTP client, DB pool, schema cache) on first use, guarded by a mutex.

Before:

type Facade struct {
    mu     sync.Mutex
    client *http.Client // expensive: TLS handshake setup, pool warm-up
}

func (f *Facade) http() *http.Client {
    f.mu.Lock()
    defer f.mu.Unlock()
    if f.client == nil {
        f.client = buildClient() // 30 ms first call
    }
    return f.client
}

BenchmarkMutexLazy-8     50000000     25 ns/op    0 B/op    0 allocs/op

Every call after init still pays for Lock/Unlock. Under contention, the mutex serialises all callers.

type Facade struct {
    once   sync.Once
    client *http.Client
}

func (f *Facade) http() *http.Client {
    f.once.Do(func() { f.client = buildClient() })
    return f.client
}

BenchmarkOnceLazy-8     500000000     2.4 ns/op    0 B/op    0 allocs/op

# Verify contention is gone
go test -bench=Lazy -mutexprofile=mu.pprof
go tool pprof -top mu.pprof

Exercise 7 — Many small subsystem calls instead of batching¶

Scenario: A facade iterates a list and calls a subsystem method per item. Each call has fixed overhead (network round-trip, lock acquisition, syscall). The total overhead dominates.

Before:

type UserFacade struct{ db *DBClient }

func (f *UserFacade) ActivateAll(ctx context.Context, ids []int64) error {
    for _, id := range ids {
        if err := f.db.SetActive(ctx, id, true); err != nil {
            return err
        }
    }
    return nil
}

Each SetActive issues one DB round-trip (~1 ms).

BenchmarkPerItemCall-8    50    20_000_000 ns/op    1024 B/op    20 allocs/op

For 1000 IDs, that's 1 second.

func (f *UserFacade) ActivateAll(ctx context.Context, ids []int64) error {
    return f.db.SetActiveBatch(ctx, ids, true)
}

// In the DB layer:
func (c *DBClient) SetActiveBatch(ctx context.Context, ids []int64, active bool) error {
    _, err := c.conn.ExecContext(ctx,
        "UPDATE users SET active = $1 WHERE id = ANY($2)",
        active, pq.Array(ids))
    return err
}

BenchmarkBatchCall-8    5000    220_000 ns/op    96 B/op    3 allocs/op

# Measure the wall-clock for a representative batch
go test -bench=Activate -benchtime=10x -count=5

Exercise 8 — PGO devirtualization for hot facade methods¶

Scenario: The facade holds its subsystems as interfaces (good for testing/mocking). In production, the concrete implementations are fixed (only one production type per interface), but the interface dispatch still pays for itab lookup on every call.

Before:

type Cache interface{ Get(string) ([]byte, bool) }
type DB    interface{ Query(string) ([]byte, error) }

type Facade struct {
    cache Cache
    db    DB
}

func (f *Facade) Fetch(key string) ([]byte, error) {
    if b, ok := f.cache.Get(key); ok { // interface dispatch
        return b, nil
    }
    return f.db.Query(key) // interface dispatch
}

In production, cache is always *redisCache and db is always *postgres.

BenchmarkFacadeIface-8     5000000     280 ns/op

# Option A: from a benchmark
go test -bench=Fetch -cpuprofile=cpu.pprof -benchtime=30s

# Option B: from a running service
curl -o cpu.pprof http://localhost:6060/debug/pprof/profile?seconds=30

# Apply PGO
mv cpu.pprof default.pgo
go build -pgo=auto . # auto picks up default.pgo

BenchmarkFacadePGO-8     9000000     150 ns/op

# Compare with and without PGO on the same benchmark
go test -bench=Fetch -count=10 > nopgo.txt
go test -bench=Fetch -pgo=default.pgo -count=10 > pgo.txt
benchstat nopgo.txt pgo.txt

Exercise 9 — fmt.Sprintf in facade error wrapping¶

Scenario: The facade wraps subsystem errors with context, using fmt.Sprintf or fmt.Errorf with multiple verbs. On the success path, this is unused — but error wrapping appears on every error return, and for high-error-rate facades (e.g. validation) it dominates.

Before:

func (f *OrderFacade) PlaceOrder(ctx context.Context, o Order) error {
    if err := f.inventory.Reserve(ctx, o.Items); err != nil {
        return fmt.Errorf("order %d: inventory reserve for user %d failed: %w", o.ID, o.UserID, err)
    }
    if err := f.billing.Charge(ctx, o.UserID, o.Total); err != nil {
        return fmt.Errorf("order %d: billing charge user %d amount %.2f failed: %w", o.ID, o.UserID, o.Total, err)
    }
    // ...
    return nil
}

When inventory often fails (e.g. out-of-stock during a flash sale, 30% error rate):

BenchmarkFmtErrorf-8     3000000    420 ns/op    192 B/op    5 allocs/op

Each error path allocates the formatted string, the wrapping error struct, and a couple of intermediate interfaces.

type OrderError struct {
    OrderID int64
    UserID  int64
    Stage   string // "inventory", "billing", "shipping", "notification"
    Err     error
}

func (e *OrderError) Error() string {
    var sb strings.Builder
    sb.Grow(64)
    sb.WriteString("order ")
    sb.WriteString(strconv.FormatInt(e.OrderID, 10))
    sb.WriteString(": ")
    sb.WriteString(e.Stage)
    sb.WriteString(" failed: ")
    sb.WriteString(e.Err.Error())
    return sb.String()
}

func (e *OrderError) Unwrap() error { return e.Err }

func (f *OrderFacade) PlaceOrder(ctx context.Context, o Order) error {
    if err := f.inventory.Reserve(ctx, o.Items); err != nil {
        return &OrderError{OrderID: o.ID, UserID: o.UserID, Stage: "inventory", Err: err}
    }
    if err := f.billing.Charge(ctx, o.UserID, o.Total); err != nil {
        return &OrderError{OrderID: o.ID, UserID: o.UserID, Stage: "billing", Err: err}
    }
    return nil
}

BenchmarkTypedError-8     20000000     85 ns/op     32 B/op    1 allocs/op

# Identify hot error paths
go test -bench=. -cpuprofile=cpu.pprof
go tool pprof -list 'fmt\.Errorf|fmt\.Sprintf' cpu.pprof

Exercise 10 — Facade caching subsystem results for read-heavy workloads¶

Scenario: A facade's Get method calls into a slow subsystem (DB, remote API). The same key is requested repeatedly within a short window. Each request pays the full cost.

Before:

type ConfigFacade struct{ store *ConfigStore }

func (f *ConfigFacade) Get(ctx context.Context, key string) (Config, error) {
    return f.store.Fetch(ctx, key) // ~2 ms per call (DB round-trip)
}

BenchmarkUncachedGet-8     500    2_000_000 ns/op    128 B/op    3 allocs/op

Workload: 90% of requests hit a hot set of 50 keys.

type cacheEntry struct {
    cfg     Config
    expires int64 // unix nanos
}

type ConfigFacade struct {
    store *ConfigStore
    cache sync.Map // key -> *cacheEntry
    ttl   time.Duration
}

func (f *ConfigFacade) Get(ctx context.Context, key string) (Config, error) {
    if v, ok := f.cache.Load(key); ok {
        e := v.(*cacheEntry)
        if time.Now().UnixNano() < e.expires {
            return e.cfg, nil
        }
    }
    cfg, err := f.store.Fetch(ctx, key)
    if err != nil {
        return Config{}, err
    }
    f.cache.Store(key, &cacheEntry{
        cfg:     cfg,
        expires: time.Now().Add(f.ttl).UnixNano(),
    })
    return cfg, nil
}

BenchmarkCachedHit-8     50000000     45 ns/op     0 B/op    0 allocs/op

v, err, _ := f.sf.Do(key, func() (any, error) {
    cfg, err := f.store.Fetch(ctx, key)
    if err != nil {
        return nil, err
    }
    f.cache.Store(key, &cacheEntry{cfg: cfg, expires: time.Now().Add(f.ttl).UnixNano()})
    return cfg, nil
})

# Measure hit rate and effective latency
go test -bench=Get -benchtime=10s
# Add instrumentation: count hits vs misses, log hit rate periodically.

Exercise 11 — Facade per request instead of reused with injected state¶

Scenario: An HTTP handler builds a fresh facade per request, populating it with request-scoped state (user ID, tenant, trace context). The facade construction allocates several fields and possibly opens subsystem resources.

Before:

type RequestFacade struct {
    userID   int64
    tenant   string
    traceID  string
    cache    *Cache
    db       *DB
    logger   *Logger
    metrics  *Metrics
    requests []Request
}

func handler(w http.ResponseWriter, r *http.Request) {
    f := &RequestFacade{
        userID:   userIDFromCtx(r.Context()),
        tenant:   tenantFromCtx(r.Context()),
        traceID:  traceIDFromCtx(r.Context()),
        cache:    globalCache,
        db:       globalDB,
        logger:   globalLogger.With("trace", traceIDFromCtx(r.Context())),
        metrics:  globalMetrics,
        requests: make([]Request, 0, 8),
    }
    handleRequest(f, r)
}

BenchmarkPerRequestFacade-8    1000000    1450 ns/op    864 B/op    9 allocs/op

At 50k RPS, that's ~45 MB/s of allocation pressure just for facade construction.

type Facade struct { // built once at startup
    cache   *Cache
    db      *DB
    logger  *Logger
    metrics *Metrics
}

type ReqCtx struct {
    UserID  int64
    Tenant  string
    TraceID string
}

func (f *Facade) Handle(ctx context.Context, rc ReqCtx, r Request) error {
    log := f.logger.With("trace", rc.TraceID)
    // ... use f.cache, f.db, log, etc.
    return nil
}

func handler(w http.ResponseWriter, r *http.Request) {
    rc := ReqCtx{
        UserID:  userIDFromCtx(r.Context()),
        Tenant:  tenantFromCtx(r.Context()),
        TraceID: traceIDFromCtx(r.Context()),
    }
    facade.Handle(r.Context(), rc, parseRequest(r))
}

BenchmarkSharedFacade-8     30000000     80 ns/op     0 B/op    0 allocs/op

# Confirm the construction allocations are gone
go test -bench=Handle -benchmem
go test -bench=Handle -memprofile=mem.pprof
go tool pprof -alloc_objects mem.pprof

Exercise 12 — Reflection-based dispatch replaced by direct method calls¶

Scenario: The facade dispatches to subsystems using reflection — typically because of a generic "command bus" or "RPC server" abstraction inside the facade.

Before:

type Facade struct {
    handlers map[string]reflect.Value // method values
}

func NewFacade(svc *Service) *Facade {
    f := &Facade{handlers: make(map[string]reflect.Value)}
    v := reflect.ValueOf(svc)
    f.handlers["CreateUser"] = v.MethodByName("CreateUser")
    f.handlers["DeleteUser"] = v.MethodByName("DeleteUser")
    f.handlers["UpdateUser"] = v.MethodByName("UpdateUser")
    return f
}

func (f *Facade) Dispatch(name string, args ...any) ([]any, error) {
    m, ok := f.handlers[name]
    if !ok {
        return nil, fmt.Errorf("unknown method %s", name)
    }
    in := make([]reflect.Value, len(args))
    for i, a := range args {
        in[i] = reflect.ValueOf(a)
    }
    out := m.Call(in)
    res := make([]any, len(out))
    for i, o := range out {
        res[i] = o.Interface()
    }
    return res, nil
}

BenchmarkReflectDispatch-8     500000    3500 ns/op    640 B/op    16 allocs/op

Every call: map lookup + N reflect.ValueOf calls + Call (which itself uses reflection to set up the stack frame) + N Interface() boxings.

type Facade struct{ svc *Service }

func (f *Facade) CreateUser(ctx context.Context, name string) (int64, error) {
    return f.svc.CreateUser(ctx, name)
}

func (f *Facade) DeleteUser(ctx context.Context, id int64) error {
    return f.svc.DeleteUser(ctx, id)
}

func (f *Facade) UpdateUser(ctx context.Context, id int64, name string) error {
    return f.svc.UpdateUser(ctx, id, name)
}

id, err := facade.CreateUser(ctx, "alice")

BenchmarkDirectCall-8    200000000     12 ns/op     0 B/op    0 allocs/op

BenchmarkClosureDispatch-8    5000000     280 ns/op    96 B/op    2 allocs/op

# Profile to confirm reflect overhead
go test -bench=Dispatch -cpuprofile=cpu.pprof
go tool pprof -list 'reflect\..*' cpu.pprof

When NOT to optimize¶

Most facade-related optimisations are micro-optimisations. They matter only if:

1. Profiling shows the facade is a bottleneck. Most of the time, the subsystems behind the facade dominate. The facade adds 1-10 ns per call; the subsystem call is 1 μs to 1 ms. Optimising the facade is the wrong place to look unless it's allocating like a maniac, holding a global lock, or serialising work that could parallelise.
2. The QPS is high enough to matter. A 100 ns saving × 10 QPS = 1 μs/sec. Irrelevant.
3. The clarity loss is acceptable. A facade exists to provide a clean surface. Optimisations that drag subsystem implementation details into the facade signature defeat its purpose.

The right order: measure → identify hot paths → optimise selectively → measure again.

go test -bench=. -cpuprofile=cpu.pprof -memprofile=mem.pprof
go tool pprof -top -cum cpu.pprof
go test -bench=. -count=10 > before.txt # apply change, then re-run
benchstat before.txt after.txt

Premature optimisation of facades is a classic time-waster. The pattern is already efficient on the dispatch side — Go's compiler handles the common cases well. The exceptions almost always worth doing without measurement:

• sync.Once for lazy init of subsystems (Exercise 6).
• Avoid a global lock around the whole flow when subsystems have their own locking (Exercise 1).
• Don't construct a fresh facade per request when state can be injected (Exercise 11).
• Don't recompile regexes, recompile templates, or rebuild fixed config inside the facade.

Everything else: measure first.

Summary¶

Wins that always ship: - sync.Once for lazy subsystem init (Exercise 6). - Drop the global lock when subsystems have internal locking (Exercise 1). - Reuse the facade with injected per-request state instead of constructing it per request (Exercise 11). - Compile-time interface check (var _ FacadeIface = (*Facade)(nil)).

Wins behind a profile: - Parallelise independent subsystem calls with errgroup (Exercise 2). - Reuse buffers via sync.Pool for hot facade-to-subsystem arg shapes (Exercise 3). - Cache read-heavy subsystem results with TTL + singleflight (Exercise 10). - Batch many small subsystem calls into one (Exercise 7). - Replace fmt.Errorf on hot error paths with typed errors (Exercise 9). - Replace reflection-based dispatch with direct or closure-table calls (Exercise 12).

Wins that trade off flexibility: - Return concrete types instead of interfaces from facade methods (Exercise 4). - Replace mutex with atomic for simple counter state (Exercise 5).

Rarely worth it without measurement: PGO devirtualization (Exercise 8) — only for hot, stable services with a representative profile.

Most facade performance work is avoiding serialisation and moving cost off the hot path. The three patterns most engineers hit first — global lock around everything (Exercise 1), serial calls to independent subsystems (Exercise 2), per-request facade construction (Exercise 11) — fix the majority of facade-related hotspots in real services with no measurement needed.