Cloud Sandbox

Borough Furniture Store

bfstore

A production-oriented engineering case study tracing Borough Furniture Store from business requirements through application architecture, developer platform design and cloud implementation.

Last updated:

What Is bfstore?

bfstore is an engineering project built around Borough Furniture Store, a fictional UK-based online retailer selling developer-themed homeware to customers across the UK and EU.

The business provides a stable setting for one question: how does an idea become software that can be built, deployed, secured, observed, operated and changed? Rather than documenting cloud-native technologies in isolation, bfstore shows where they fit, why they were selected and which requirements they address.

The project has three connected layers: application, developer platform and cloud implementations. Architecture decisions, operational practices and implementation evidence connect the layers, so readers can move from a design claim to the artefacts that support it.

Project Snapshot

This snapshot shows what is being built, how the main layers relate and which areas are implemented, in progress or planned.

bfstore at a glance

One project, three engineering layers

Active development

Business
Fictional UK/EU ecommerce retailer for developer-themed homeware
Application
Domain-aligned Go services, explicit contracts and service-owned data In progress
Developer platform
The path from source change to a governed, deployable, observable and operable workload Planned
Cloud
AWS first, followed by provider-native implementations on Azure and Google Cloud AWS in progress
Application communication
Protocol Buffers and gRPC for synchronous contracts; business events for asynchronous workflows
Data ownership
Service-owned persistence with explicit transaction and consistency boundaries
Infrastructure
OpenTofu, Kubernetes, GitOps and policy-driven delivery as the platform develops
Evidence
Source code, contracts, ADRs, infrastructure, tests, experiments, diagrams and runbooks

The Business Story

Roadmap showing bfstore progressing from business requirements through application, developer platform and cloud implementation

Borough Furniture Store begins as a small retailer with a playful product range and a comparatively simple application. Growth introduces more customers, a larger engineering team, a broader roadmap and higher expectations for availability, delivery and change.

Those pressures justify the engineering work. Service boundaries, asynchronous workflows, platform capabilities, cloud governance and operational controls are introduced to meet specific needs, not to complete a cloud-native checklist.

The Business & Domain area documents the business context, domain model, rules, requirements and customer journeys.

The Engineering Challenge

bfstore is large enough for decisions in one part of the system to affect another. A checkout request crosses service contracts, data ownership, failure handling, telemetry, workload identity, deployment, networking, infrastructure policy and recovery.

The question is not whether one feature or tool works in isolation. It is whether a business capability has the application, platform and cloud foundations to behave predictably during change or failure.

Design Principles

A small set of principles keeps the project coherent as the application, developer platform and cloud implementations develop at different rates.

  • Begin with business behaviour. Customer journeys, domain rules and requirements come before infrastructure products.
  • Keep ownership explicit. Services own their responsibilities and data; platform and cloud boundaries have named purposes.
  • Make contracts visible. APIs, events, infrastructure interfaces and policies should be reviewable and testable.
  • Prefer evidence to architecture theatre. Designs link to implementation, validation, operational artefacts and known limitations.
  • Use each cloud natively. AWS, Azure and Google Cloud meet the same bfstore requirements through their own governance, identity, networking and service models rather than forced one-to-one mappings.
  • Keep it boring where production matters. Clarity, recoverability and operability win over novelty when a simpler choice does the job.

Significant choices and trade-offs are recorded in the Architecture Decisions library, keeping the reasoning visible without repeating the same history across implementation pages.

From Business Idea To Running System

Readers can follow roughly the same sequence as the engineering work: business behaviour, software design, developer enablement, cloud implementation and operational proof.

  1. Business Idea And Requirements. Define what Borough Furniture Store does, who interacts with it and the rules the system must preserve.
  2. Application. Turn those capabilities into services, contracts, data boundaries, events and end-to-end workflows.
  3. Developer Platform. Provide repeatable ways to build, test, provision, deploy, observe and operate those services.
  4. Cloud Implementations. Realise the requirements through provider-native organisation, identity, governance, networking, security, runtime and data services.
  5. Operate And Prove It. Use SLOs, runbooks, tests, experiments, recovery exercises and repository evidence to validate the design.

Explore bfstore

This page serves as a map of the wider project. Each area below provides a deeper route into the engineering work without losing its business context.

Application

Follow Borough Furniture Store's behaviour into domain rules, customer journeys, service boundaries, contracts, data, events and workflows.

ApplicationExplore the bfstore application

Follow the business domain into application architecture, cross-service workflows and the design of each service.

Developer Platform

Follow a source change towards a governed, deployable and observable workload, including CI, infrastructure provisioning, Kubernetes, GitOps, self-service, security, secrets and platform reliability.

Developer platformExplore the bfstore developer platform

See the capabilities and golden paths that make building, deploying and operating bfstore repeatable.

Cloud Implementations

See how common bfstore requirements are realised through each provider's organisation, identity, governance, networking and service models rather than using one cloud as the template for another.

CloudExplore the cloud implementations

Start with provider-neutral requirements, then follow the AWS, Azure and Google Cloud implementation stories.

Cross-Cutting Engineering

Decisions, operations and evidence provide the reasoning, practices and proof that connect the application, platform and cloud layers.

DecisionsArchitecture decision records

The context, options, trade-offs and outcomes behind significant bfstore engineering choices.

 OperationsOperating bfstore

SLOs, runbooks, incident response, recovery, capacity and the practices used to keep the system operable.

 EvidenceProving the design

Repositories, tests, experiments, diagrams and implementation status that connect the written architecture to working artefacts.

A Customer Journey Through The Architecture

Customer journeys connect the fictional business to the distributed system. Checkout is especially useful because one customer action crosses several service and operational boundaries.

  1. Browse the product catalogue.
  2. Add one or more products to a basket.
  3. Begin checkout.
  4. Validate and reserve inventory.
  5. Authorise payment.
  6. Create the order.
  7. Trigger fulfilment and customer notification.

The workflow documentation traces synchronous calls, resulting events, data changes, telemetry and failure paths, showing how a simple customer action becomes end-to-end system behaviour.

Application workflowsFollow bfstore across service boundaries

Explore customer and business workflows as end-to-end system behaviour rather than isolated service diagrams.

Implementation Status

bfstore is built in slices. The documentation separates implemented behaviour from designs being validated or planned, recording progress instead of describing an imagined finished state.

Current implementation status by project area
Area Status Current focus
Application In progress Core ecommerce services, contracts and the first end-to-end business journeys
Developer Platform Planned Platform capabilities and golden paths after the application and cloud foundations mature
AWS In progress Organisation, identity, governance, networking, IPAM and infrastructure foundations
Azure Planned Provider-native Azure implementation after the AWS implementation is complete
Google Cloud Planned Provider-native Google Cloud implementation after Azure

Detailed progress, validation results and future work are maintained in the implementation status and roadmap pages.

Project Evidence

Implemented design claims link to concrete evidence such as repositories, code, tests and operational artefacts.

The project spans repositories with distinct responsibilities:

Repository mapSee how the bfstore repositories fit together

Map documentation and architectural responsibilities to the repositories that implement and validate them.

Roadmap

The roadmap follows the project's dependency chain. Evidence from earlier implementation work shapes later layers.

  1. Deepen the application. Continue implementing the core business journeys, service contracts, persistence, events, failure handling and telemetry.
  2. Complete the AWS foundation. Turn the organisation, identity, governance, networking and IPAM designs into tested infrastructure and reusable OpenTofu modules.
  3. Build the developer platform. Bring delivery, GitOps, Kubernetes, self-service, policy, secrets and observability into coherent developer golden paths.
  4. Implement bfstore natively on Azure, then Google Cloud. Preserve the business and platform requirements while allowing each provider's architecture to shape the implementation.
  5. Build the separate multi-cloud capstone. After the three single-cloud implementations exist, explore what should be abstracted and what should remain provider-native.

As implementation produces better evidence, the documentation records what was required, chosen, built, tested, learned and changed.