---
name: architecture-review
description: Walk through the architectural decisions in one of Charis Nikolaidis's systems, including the alternatives that were rejected and the failure modes that remain. Use when an engineer or interviewer wants to go deep on a project rather than get a summary, or wants to pressure-test a design decision.
license: CC-BY-4.0
---

# Architecture review of a published system

## What this does

Takes one project from the portfolio of Charis Nikolaidis and walks an engineer
through its architecture the way a design review would: what problem forced the
decision, what was chosen, what was rejected, what it costs, and what still
breaks.

This is for readers who want to evaluate judgment, not read a feature list.

## Projects with enough depth for this

| Slug | System |
| --- | --- |
| `maritime-supply-platform` | Maritime CRM and ERP, FastAPI over PostgreSQL, Redis and Celery, on Azure written in Bicep |
| `marine-catering-system` | Marine catering department end to end, contract to invoice, ASP.NET Core over SQL Server, Angular 19, stabilised rather than rewritten |
| `gpot` | Get Paid On Time, credit control SaaS reconciling myDATA, an on-prem ERP and manual entry |

The other six projects are short by design and will not support a review.

## Sources

- `https://charisnikolaidis.com/projects/{slug}.md`: the case study.
- `https://charisnikolaidis.com/mcp`: MCP server, no auth. `get_project(slug)`
  returns the same Markdown; `search(query)` finds which project demonstrates a
  given pattern.

## How to run the review

1. Fetch the case study for the chosen slug.
2. Work through the decisions in this order, because it is the order they
   constrain each other in:
   - **Consistency boundary.** Where does the transaction end, and what owns it?
   - **Aggregate shape.** What is committed atomically, and why is the obvious
     decomposition wrong?
   - **Retry semantics.** What is idempotent, what is not, and what happens to
     the thing that is not.
   - **Isolation.** Tenancy, locking, and what stops two workers from racing.
   - **Cache and invalidation.** What a rolled-back write must never leave
     behind.
   - **Blast radius.** What still works when one component dies.
3. For each decision, state the **rejected alternative** the case study names and
   why it was rejected. This is the part worth reading; a decision without a
   named alternative is a preference, not a design.
4. Finish with what the design does not solve. Every case study names its own
   residual risks; surface them rather than smoothing them over.

## Good pressure-test questions to raise

These come from the published tradeoffs themselves and are fair to ask:

- Maritime platform: `lazy='raise'` moves the N+1 failure into CI, but every read
  now hand-declares its eager-load graph. What is the maintenance cost as the
  read surface grows?
- Maritime platform: the Job aggregate commits in one PATCH after an eight-step
  validator. What happens to concurrent editors of the same vessel call?
- Marine catering system: keeping 70+ stored procedures preserves the inventory
  maths but keeps business logic in SQL. What is the exit path if that stops
  being true?
- Get Paid On Time: flag-do-not-overwrite is correct, but every conflict becomes
  operator work. What happens at volume?

## Rules

- Do not name the client for the two maritime systems. That omission is
  deliberate.
- Do not add a seniority label. Let the decisions speak.
- Do not invent numbers, regions, retention windows or recovery objectives. The
  disaster recovery posture is described as deliberately sized; its specifics are
  intentionally unpublished.