Course outline

01 · Introduction to the Meridian Platform3/3

02 · Workspace Layout, Design Principles, and the Platform Library5/5

03 · The Data Layer4/4

04 · Identity Service: HTTP API Layer4/4

05 · Authentication and Authorization4/4

06 · The Gateway Service2/2

07 · Testing Strategy5/5

08 · Caching and Rate Limiting3/3

09 · Background Processing3/3

10 · File Storage2/2

11 · Event-Driven Communication3/3

12 · Resilience Patterns2/2

13 · Observability3/3

14 · Advanced PostgreSQL3/3

15 · API Versioning and the Platform Contract2/2

16 · Containerization and Deployment4/4

17 · CI/CD Pipeline2/2

18 · Security Hardening2/2

19 · Capstone: System Integration2/2

20 · Retrospective2/2

Stage 7 · Master

Workspace Layout, Design Principles, and the Platform Library

The Platform Library

libs/platform's five packages — config, logging, errors, response, and tenancy — and the shared conventions they enforce across every service.

15 min readMeridian: A Multi-Tenant Go PlatformMaster

Why a Shared Library

Four independently deployed services need identical conventions for configuration, logging, error shape, and tenant propagation — otherwise each service reinvents its own, and cross-service log correlation and API consistency break down. libs/platform holds five small packages implementing these conventions once, imported by every service module via the go.work replace directive established in the previous chapter.

config

Golibs/platform/config/config.go.go

10 linesLn 1, Col 1Go

A single helper: read an environment variable, fall back to a default if unset. Every service's internal/config.Load() function calls this for each setting, matching the values documented in .env.example.

logging

Golibs/platform/logging/logging.go.go

12 linesLn 1, Col 1Go

Built on the standard library's log/slog. Every logger created by every service is tagged with a "service" attribute, so JSON logs from gateway, identity-service, community-service, and billing-service interleave cleanly in any log aggregator without a separate correlation step.

errors and response — the Platform Contract

The Platform Contract is the API shape shared between every Meridian service and meridian-web, the frontend BFF. Success responses look like { data, meta?, error: null }; failures look like { code, message, trace_id, details? }. Both shapes are implemented as Go types in libs/platform today, though no handler yet constructs them — see Current Adoption Status below.

Golibs/platform/errors/errors.go.go

26 linesLn 1, Col 1Go

APIError implements Go's error interface via Error(), so it can be returned and handled like any other error while still carrying the structured fields the Platform Contract requires on the wire.

Golibs/platform/response/response.go.go

21 linesLn 1, Col 1Go

A generic envelope parameterized over the payload type T. OK() wraps a single resource or list with no pagination metadata; OKWithMeta() attaches paging metadata for list endpoints. Chapter 4 covers where handlers will construct these once implemented.

tenancy

Golibs/platform/tenancy/tenancy.go.go

18 linesLn 1, Col 1Go

Fixes the vocabulary for tenant propagation: a single header constant, and context helpers to attach and retrieve the resolved tenant UUID. No middleware yet reads this header or populates the context — that is built in Chapter 6, when the gateway begins forwarding tenant identity to internal services.

Current Adoption Status

Implemented but not yet consumed

All five packages compile and are unit-tested today. No service handler currently constructs a response.Envelope, returns an errors.APIError, or reads a tenancy.TenantIDHeader — every service's only route is /healthz, which predates the need for any of these types. Chapters 4 through 6 are where each package is first put to use by a real handler.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.