Loading...
Getting data from various sources...
This may take a few seconds...
Getting data from various sources...
This may take a few seconds...
My approach to system design is grounded in clear domain boundaries, explicit contracts between layers, and building for failure — not just the happy path.
Domain-Driven Design
Bounded contexts, aggregates, value objects, and domain events enforced in AtlasPay and Errandy.
Hexagonal Architecture
Domain and Application layers stay pure; Infrastructure adapters depend inward, not the reverse.
Event-Driven Architecture
Kafka for async payment flows and domain event propagation. Retry, DLQ, and idempotent consumers.
Saga / Process Managers
Errandy uses AcceptApplicationProcessManager to orchestrate: payment → accept → assign → escrow → chat.
Observability & Reliability
Correlation IDs, failure classification, retry mechanisms, dead-letter queues, and health checks.
Database Engineering
Relational modeling, transaction isolation, optimistic/pessimistic locking, index design, migrations.
AtlasPay — Layered Architecture
Client → REST API → Application Service
↓
Domain Layer
(Identity · Accounts · Ledger · Transfers)
↓
Infrastructure Adapters
PostgreSQL · Kafka · Redis