§02 / services / architecting
Architecting
Decisions that age well, not ones that dazzle.
We design systems that stay legible after twelve months and three teams. Predictable beats clever.
FIG. 02.0architecting
§02.1/ capabilities
What we ship.
- 02.1Service boundaries drawn from the business domain, not from the org chart
- 02.2Event-driven integration: change-data-capture, durable queues, exactly-once delivery
- 02.3High-availability designs with concrete recovery, throughput, and error-budget targets
- 02.4Pragmatic migration roadmaps, taken only when the move earns its keep
- 02.5Compliance-aware architecture: GDPR, audit trails, and threat models built in from day one
- 02.6Architecture documentation that stays useful long after the engagement ends
§02.2/ stack
Tools in hand.
Domain-Driven DesignEvent SourcingCQRSC4 ModelOpenAPIAsyncAPIKafkaDebezium (CDC)PostgreSQLRedis
§02.3/ artifact
In production.
A sample of what an engagement actually looks like in code.
# c4 / orders bounded context
context:
name: orders
language: kotlin
inbound:
- kind: http
contract: openapi://orders.v1.yaml
- kind: kafka
topic: payments.completed.v1
outbound:
- kind: kafka
topic: orders.placed.v1
retention: 7d
storage:
primary: postgresql/orders
cache: redis/orders-idx
guarantees:
- idempotency: header X-Idem-Key
- delivery: at-least-once