There is a furniture shop hiding inside this engineering project.
It sells Gopher reading chairs, Rivest lockboxes, Kubernetes plant pots and a distributed systems coffee table whose coffee is, naturally, eventually consistent.
The shop is fictional.
The engineering problems are not.
bfstore, short for Borough Furniture Store, is the project I use to explore a much bigger question:
What does it actually take to turn a business idea into a system that can be built, deployed, secured, observed, operated and changed with confidence?
That question has gradually made bfstore much more than an ecommerce application.
It is deliberately production-shaped: the business is fictional, but the engineering constraints are treated seriously.
It has become the place where I bring together application architecture, distributed systems, developer platforms, cloud infrastructure, security, operations and the engineering decisions connecting them.
Why a furniture store?
I wanted a project with a business domain that was easy to understand but capable of becoming technically interesting.
An online shop provides plenty to work with.
A customer can:
browse products
│
▼
add something to a basket
│
▼
begin checkout
│
▼
reserve inventory
│
▼
authorise payment
│
▼
create an order
│
▼
arrange fulfilment
│
▼
receive a notification
On the surface, that is just a customer buying a chair.
From an engineering perspective, it quickly raises harder questions.
What owns the basket?
What happens if payment succeeds but order creation fails?
How should inventory be reserved?
Which interactions should be synchronous?
Which events belong on a message broker?
Where are transaction boundaries?
How does a developer deploy a change?
Which identity does the workload use?
How is the system observed?
What happens when part of it becomes unavailable?
How is the infrastructure recovered?
And how can I demonstrate that the answers exist in working code and infrastructure rather than only in an architecture diagram?
That is where bfstore becomes useful.
One project, three engineering layers
I organise bfstore around three connected layers:
bfstore
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
APPLICATION PLATFORM CLOUD
The application
The application is the business system itself.
It explores domain-aligned services, service-owned data, explicit contracts, synchronous communication and asynchronous business workflows.
The current direction includes Go services with Protocol Buffers and gRPC for synchronous contracts, alongside business events for workflows that cross service boundaries.
But the interesting part is not simply assembling a collection of technologies.
The question is always:
What business or engineering requirement made this design necessary?
A service boundary should have a reason.
An event should have a reason.
A database boundary should have a reason.
A retry should have a reason.
Technology is part of the solution, not the plot.
The developer platform
Writing application code is only one part of delivering software.
Eventually a source change needs a reliable path towards becoming a running workload.
That means thinking about:
source
│
▼
build and test
│
▼
infrastructure
│
▼
deployment
│
▼
policy and security
│
▼
observability
│
▼
operations
The developer-platform layer of bfstore explores how that path can become repeatable rather than being rediscovered by every service and every engineer.
This is where areas such as Kubernetes, GitOps, infrastructure provisioning, secrets, policy, developer self-service and platform reliability begin to meet.
The goal is not to hide engineering behind a magical internal portal.
It is to remove unnecessary toil while keeping important system behaviour visible.
The boundary I am keeping in mind is simple: the platform layer is about the developer and workload experience built on top of infrastructure, while the cloud layer is about the provider-specific foundations that make that platform and those workloads possible.
The cloud implementations
The third layer is cloud infrastructure.
bfstore begins with AWS.
Azure follows.
Then Google Cloud.
The intention is deliberately not to build an AWS architecture and rename every box until it looks vaguely Azure-shaped.
Each cloud implementation starts with the same underlying bfstore requirements, then uses that provider’s own organisation, identity, governance, networking and service models.
That distinction matters to me.
Multi-cloud should not require pretending that three different platforms are secretly the same platform wearing different logos.
First I want to understand how to build bfstore well on each cloud individually.
Only after those implementations exist does it make sense to ask what should genuinely be abstracted across them.
Business behaviour comes first
One rule sits underneath the project:
Start with the behaviour the system needs to preserve.
That means the journey does not begin with Kubernetes.
It does not begin with an AWS service diagram.
It begins with questions such as:
What does Borough Furniture Store do?
Who interacts with it?
What rules must always hold?
What happens during checkout?
What happens when something fails?
What must be recoverable?
Those answers shape the software.
The software creates requirements for the platform.
The application and platform create requirements for the cloud infrastructure.
So the direction is intentionally:
business
│
▼
application
│
▼
platform
│
▼
cloud
│
▼
operations and evidence
rather than:
interesting technology
│
▼
find somewhere to use it
The latter is tremendous fun in a sandbox.
It is a fairly dangerous architecture strategy.
Architecture needs receipts
This has become one of my favourite principles in the project:
Prefer evidence to architecture theatre.
A box on a diagram is a claim.
Eventually I want to be able to follow that claim somewhere concrete.
The bfstore documentation is therefore being built so that a reader can move through a chain such as:
requirement
│
▼
design
│
▼
architecture decision
│
▼
implementation
│
▼
test or experiment
│
▼
operational evidence
Depending on the area, that evidence might include:
source code
Protocol Buffer contracts
ADRs
OpenTofu
tests
policy
experiments
diagrams
runbooks
recovery exercises
The goal is not merely to say:
“I would design it this way.”
The more interesting journey is:
“Here was the requirement, here was the decision, here is what I built, here is how I tested it, and here is what I learned when reality disagreed with the diagram.”
Reality is very good at code review.
The project is deliberately unfinished
bfstore is not presented as a completed production retailer.
It is a production-shaped engineering project under active development.
That distinction is important.
The project develops in stages, and different parts mature at different times.
The documentation therefore distinguishes between what has been:
implemented
what is:
in progress
and what remains:
planned
I prefer that to presenting a beautifully complete diagram and quietly asking the reader not to enquire whether any of it exists.
Failure is part of the architecture
A checkout is especially useful because it refuses to stay inside one tidy box.
One customer action can cross:
service contracts
data ownership
network boundaries
transactions
events
workload identity
infrastructure
telemetry
failure handling
recovery
So bfstore gives me somewhere to explore not just:
How does this work when everything works?
but:
What happens when the surrounding system is changing or failing?
That is a much more interesting engineering question.
Retries, idempotency, transactional boundaries, message delivery, degraded dependencies, observability, SLOs, backups and recovery all become part of the system rather than a final “production concerns” chapter bolted onto the end.
Keep it boring where production matters
There is another principle running through bfstore:
Keep it boring where production matters.
That does not mean avoiding new technology.
It means novelty has to earn its place.
Where a simple, understandable and recoverable design solves the problem, complexity does not receive bonus points for wearing a conference badge.
I would rather be able to explain:
what this component does
why it exists
how it fails
how it is observed
how it is recovered
than have the most exciting diagram in the room.
What bfstore is really documenting
The furniture store gives the project a story.
The deeper subject is engineering evolution.
The evidence tells me whether a design works.
The history explains why the design became what it is.
As bfstore develops, I am documenting:
what was required
│
▼
what I considered
│
▼
what I chose
│
▼
what I built
│
▼
what failed
│
▼
what I learned
│
▼
what changed next
That is why the project is spread across application design, developer platform work, cloud implementation, architecture decisions, operations and evidence.
They are not separate portfolio projects.
They are different views of the same system.
The principles I am trying to keep
The project is broad, but the working principles are fairly simple:
start from business behaviour
make architectural claims testable
treat failure and recovery as design inputs
prefer understandable systems over novelty
respect the differences between cloud platforms
Those principles are the thread connecting the application, platform and cloud work.
Explore bfstore
The main bfstore project area is the map for all of this.
From there you can follow the project into:
- the business and application architecture;
- the developer platform;
- the AWS, Azure and Google Cloud implementations;
- architecture decisions and their trade-offs;
- operational practices and runbooks;
- implementation evidence and repositories;
- the roadmap showing what exists now and what comes next.
The furniture may be fictional.
The contracts, infrastructure, failure modes, policies, tests and engineering decisions have to stand on their own.
Explore bfstore: Borough Furniture Store →
Bring your own eventually consistent coffee.