SaumilP SaumilP

I'm a systems designer who stays hands-on. By day I work in software architecture, designing systems and setting standards; after hours I build reference implementations and tools so my decisions stay grounded in working code.

When	What I do
Day job	Designing systems, recording decisions, setting standards, reviewing trade-offs.
After hours	Reference implementations, patterns and Rust tooling. Everything on this profile is personal-time work, built to keep my judgment sharp.

What I focus on

Area	What it looks like in practice
Service design and boundaries	Domain-driven design, modular monoliths before microservices, clear ownership and contracts
Resilience and observability	Timeouts, retries and backpressure designed up front; traces, metrics and logs treated as part of the design
API and integration design	REST contracts, messaging, idempotency, versioning that does not break consumers
Platform and governance	Shared starters, golden paths, CI/CD standards so teams spend their effort on the domain

Day to day	Tools I reach for
Languages
Frameworks and data
Platform and delivery

How I design

Start from the boundary, not the framework. Where responsibility ends matters more than which library sits inside it.
Write the decision down. Context, options considered, and what we gave up. A short ADR beats a long memory.
Design for failure first. Decide what happens when a dependency is slow or down before adding the feature.
Standardise the boring parts. Starters and golden paths remove repeated decisions so the interesting ones get attention.
Prefer decisions that are cheap to reverse. When unsure, pick the option that is easiest to change later.

Flagship: a reference platform for testing design decisions

Status: in progress. The design below is the target. Nothing here is shipped yet, and each decision is marked Proposed until the ADR is written and the code backs it up.

A place to prototype architectural decisions with working code before relying on them. It applies the principles above in a modular service built with my own Spring Boot starters, documented with C4 diagrams, and run with observability and deployment governance from day one.

Reference platform: a client calls an API gateway that routes to Orders and Inventory modules sharing PostgreSQL. Orders publishes events through an outbox to a message broker feeding Notifications. Modules emit traces and metrics to OpenTelemetry, which feeds dashboards.

ADR	Decision	Question it answers	Status
001	Modular monolith first, split later	When is a service boundary worth a network hop?	Proposed
002	Transactional outbox for events	How do we publish events without losing or duplicating them?	Proposed
003	OpenTelemetry through a shared starter	How do teams get consistent traces and metrics for free?	Proposed
004	Policy checks in the deployment pipeline	How is governance enforced without slowing delivery?	Proposed

Planned artifacts: C4 context and container diagrams, the four ADRs above, failure-mode notes (what breaks and how it degrades), and load-test results.

Reference architecture and patterns

Worked examples of decisions I would make in practice, kept runnable and documented. Start with design-patterns for decisions in code and drawio_libraries for diagrams.