Skip to content
William Kennedy edited this page Apr 3, 2024 · 19 revisions


The service starter kit is a starting point for building production grade scalable web service applications that leverage the power of a Domain Driven, Data Oriented Architecture that can run in Kubernetes. The goal of this project is to provide a proven starting point that reduces the repetitive tasks required for a new project to be launched into production. It uses minimal dependencies, implements idiomatic code and follows Go best practices. Collectively, the project lays out everything logically to minimize guess work and enable engineers to quickly maintain a mental model for the project.

This project should not be considered a web framework. Coding is a discovery process and with that, this project leaves you in control of your project’s architecture and development. There are four areas of expertise that an engineer or their engineering team must possess for a project to be successful. Based on our experience, a few core decisions were made for each of these areas.

  • Micro level - Design philosophies and guidelines being applied to lines of code and functions. This project focuses on making things easy to understand and precision based semantics.
  • Macro level - Design philosophies and guidelines being applied to the project structure, packaging decisions, architecture, logging, configuration and production systems concerns. This project focuses on 4 layers of code, App, Business, Foundation, Vendoring. Choices around logging and configuration have been made and the use of a POD based architecture.
  • Deployment and Operations - Engineering decisions about local and production environments. Management of such environments and integrations with continuous deployment or integration systems. This project uses CircleCI for CI and Kubernetes for the compute environment.
  • Observability - Engineering decisions with the observability of logging, metrics, and tracing. Where the data is stored and how it is accessed. What kind of information will be gathered and maintained. OpenTelemetry has been chosen for tracing and the use of the expvar package for metrics.


This project contains the following features:

  • Ground up architecture and design for Kubernetes.
  • Domain Driven, Data Oriented Design
  • Separation of api protocols and app/business layer logic.
  • Configure and manage local and production K8s environments.
  • Minimal web service application framework.
  • Middleware integration.
  • Database support using Postgres.
  • CRUD based pattern.
  • Role-based access control (RBAC).
  • Account signup and user management.
  • Distributed logging and tracing.
  • Integration with OpenTelemetry for enterprise-level observability.
  • Testing patterns.
  • Use of Docker, Docker Compose, and Makefiles.
  • Vendoring dependencies with Modules, requires Go 1.18 or higher.
  • Continuous deployment pipeline.
  • Integration with CircleCI for enterprise-level CI/CD.
  • Tempo and Grafana support to collect and visualize otel traces.
  • Tooling that autogenerates documentation from reading the code.
  • Tooling that generates code for each layer when adding a new domain.

Business Problem

The service project is solving the problem of providing a backend for a sales-api that supports the running of a multi-family garage sale. Authenticated users can manage users, products and sales.


The following services are used within the scope of the project.


  • sales-admin : Command line tool to help manage the system and database.

Internal Services

  • salesapiweb : Service that provides CRUD based endpoints for the garage sale business problem.
  • metrics : Sidecar for handling support for metics data. Showcases how a sidecar can be used.

External Services

  • postgres : Database used to store users, products, and sales.
  • tempo/grafana : System used to collect and query application traces.