---
title: "System design & architecture"
description: "The decisions that are expensive to change later: service boundaries, data flow, platform choices, and the failure modes nobody priced in."
language: "en"
canonical: "https://zapolu.com/services/system-design/"
---

# System design & architecture

The expensive failures trace back to decisions made months earlier:
where the service boundaries sit, which data lives where, what happens
when a dependency is down. Those decisions are cheap on a whiteboard
and expensive in production, so that's where we spend the design time.

## What we design

- **Commerce architectures.** Storefront, backend, and the systems
  around them: ERP, PIM, WMS, payments, search. Which parts to buy,
  which to build, and where the boundaries belong.
- **Integration topologies:** event-driven versus request-driven,
  queues and dead-letter handling, idempotency, and what "eventually
  consistent" means for an order that must ship tomorrow.
- **Data flow and ownership.** One system of record per fact. Most
  integration bugs we're hired to fix trace back to two systems both
  believing they own the price.
- **Scalability and failure modes.** Load profiles for campaign
  spikes, cache strategy, graceful degradation: what customers see
  when the recommendation engine is down should be a slightly plainer
  page, not an error.
- **Migration paths.** How to get from the current architecture to
  the target one in steps that each ship value, instead of a two-year
  rewrite that delivers nothing until the very end.

## How it's delivered

Architecture work is part of most of our engagements, and it's also
available standalone: a design review of an architecture you're about
to commit to, a written target architecture with a migration plan, or
a second opinion when two vendors propose incompatible architectures. The
output is always a document your team can execute without us.

## What we optimize for

We default to boring technology and the smallest system that meets
the requirements, and we design assuming the team maintaining the
system will be smaller than the team that built it.