Distributed Systems and Event Processing
Designing systems that remain resilient when events arrive asynchronously or out of order.
- Event ordering
- Consistency and maintainability
- Kafka-based systems
- Failure handling
Senior Software Engineer and Architect
I design distributed systems, developer platforms, automation, and full-stack applications that remain understandable and maintainable as they grow.
My work replaces one-off fixes with reusable systems, reduces repetitive engineering effort, and gives teams a reliable foundation for future development.
The domains and recurring problems behind my work across software, data, infrastructure, and operations.
Designing systems that remain resilient when events arrive asynchronously or out of order.
Creating shared foundations that reduce repetitive work and make consistent engineering practices easier to maintain.
Turning business requirements into technical designs that can evolve without forcing every component to change together.
Building secure environments spanning application code, containers, networks, deployment systems, and production infrastructure.
Designing shared RTLS services that support healthcare workflows and reporting in event-driven environments.
Designing systems around their full operating life rather than treating maintenance and production behavior as later concerns.
Production systems, platform engineering, and independent R&D.
A reusable event-processing framework that improved resilience to asynchronous and out-of-order events and gave distributed services a consistent engineering approach.
Centralized Maven parent POMs and reusable Git templates reduced duplicated Spring Boot configuration and created a maintainable source of truth.
A controlled environment in which AI development agents perform ticket-driven implementation through the same branch, pull-request, CI, and review workflow used by human developers.
An end-to-end assembly-line control platform spanning physical equipment inputs, technician interfaces, application services, databases, reporting, virtualization, servers, and networks.
The technologies change. The recurring job is to find the real failure, replace repeated cases with a durable model, and leave the system easier to operate than it was before.
STEP 01
The visible error is rarely the whole problem.
Trace behavior across services, data, infrastructure, workflows, and ownership boundaries before deciding what should change.
STEP 03
Repeated work is a design problem.
Use shared libraries, parent configurations, templates, code generation, and automation to reduce boilerplate and move engineering attention toward harder problems.
STEP 04
Systems and teams need contracts that permit independent change.
Separate stable behavior from replaceable implementation details so internal changes do not force unnecessary coordination across the entire platform.
STEP 05
Deployment, recovery, observability, and maintenance affect architecture from the beginning.
A design is incomplete until failure behavior, support cost, validation, and ownership are understood.
STEP 06
Automate repeatable work without hiding important decisions.
Use tooling and agents to implement known processes while keeping code review, production approval, and accountability visible.
Operating rules with concrete consequences, not a manifesto.
The visible symptom may be several boundaries away from the underlying problem.
Trace behavior across services, events, data, infrastructure, and operational workflows before changing the system.
Out-of-order events appeared as different service bugs, but the durable solution belonged in shared platform behavior.
Examine the practiceA new conditional for every incident makes the system harder to reason about.
Identify the shared rule and move it into reusable behavior that can be tested, adopted, and maintained consistently.
The event-processing framework replaced service-specific fixes with one reusable reliability pattern.
Examine the practiceRepeated manual work is often evidence that the platform is missing a tool or source of truth.
Use shared configuration, generation, templates, and automation so future work becomes routine.
Centralized Maven parent POMs and reusable Git templates replaced repeated service-by-service setup with a shared foundation.
Examine the practiceA system's real design includes deployment, failure, observability, recovery, security, and ownership.
Evaluate how a system will be supported and changed before implementation is considered complete.
The manufacturing control system included application code, virtualization, network failover, equipment integration, and production support as one design.
Examine the practiceFourteen years of work across healthcare platforms, emergency management, manufacturing control, and medical-resupply applications.
TeleTracking
Designed event-driven healthcare systems, shared RTLS processing and reporting services, reusable platform capabilities, and microservice standards. Provided technical direction and mentoring for teams of 4–10 engineers and served as a resource for complex architecture, production, data, and maintainability problems.
BoldPlanning
Independently built the front end for a metadata-driven emergency-management document platform, developed supporting services and automated tests, and architected the AWS network environment.
Calsonic Kansei
Promoted from Systems Engineer II to Systems Engineer III
Stabilized a failing legacy assembly-line control environment and designed its replacement across industrial equipment, technician interfaces, application services, databases, reporting, virtualization, servers, and high-availability networks.
American HomePatient
Modernized a medical-resupply order-entry application and related business systems across the Java, front-end, middle-tier, and Oracle data layers.
Let's talk
Open to remote software engineering and architecture opportunities in the United States.