Payment backend
I worked on backend services around billing and payment workflows, where retries, duplicate execution, and state consistency mattered more than simple request throughput.
Product Context
MyAutoData technical context
MyAutoData is a vehicle data platform combining account-level vehicle information, trip-related data, analytics, a data marketplace, and payment flows. This page is not a product brochure. It is a technical context page for the parts of the system that are relevant to my backend work.
What It Is
Product shape
At a high level, the platform connects vehicle owners and automotive businesses around vehicle-related data. For end users, that means storing and working with vehicle information, trip-related data, analytics, and account-level product features. For businesses, it means access to structured data and workflows around offers, marketplace activity, and commercial interactions.
The important technical point is that this is not a single CRUD application. It combines static data, time-series style trip data, asynchronous processing, billing, and user-facing APIs in one domain.
50K+
active users on the platform
100K+
API requests per day in production
10K+
monthly payment transactions in Stripe-related flows
Multi-domain
vehicle data, analytics, marketplace, and payments
Domain Complexity
Why the domain is technically interesting
- The platform mixes static vehicle/account data with dynamic trip and telemetry-related data.
- Some workflows are user-facing and synchronous, while others are asynchronous and multi-step.
- Payments and payouts introduce stricter requirements for idempotency, reconciliation, and auditability.
- Marketplace and commercial flows need clean boundaries between internal state changes and external notifications.
- Privacy and user-controlled data access add constraints to how data is exposed and processed.
My Scope
System areas relevant to my work
Go services and internal APIs
My contribution centered on Go services, internal APIs, background processing, and service boundaries rather than product marketing pages or mobile app implementation.
Microservice extraction
Part of the work involved decomposing monolithic areas into focused services to improve ownership, deployment flexibility, and scaling characteristics.
Performance and reliability
I also worked on API latency and reliability improvements through Redis-backed read paths, idempotent processing, and fault-tolerant service design.
Technical Challenges
Engineering constraints behind the work
- Ensuring idempotent behavior for payment-related actions under retries and partial failures.
- Separating transactional writes from event publication in asynchronous workflows.
- Making multi-step business processes explicit and inspectable instead of distributing them across handlers and background jobs.
- Scaling selected subsystems independently rather than treating the product as a single deployable unit.
- Keeping user-facing APIs responsive while internal workflows and integrations remain eventually consistent.
My Contribution
What I can claim directly
- Built backend services in Go for payment workflows, background processing, and internal APIs.
- Built payment orchestration using Temporal, Kafka, and the Outbox pattern for deterministic multi-step processing.
- Integrated Stripe-related billing flows including retry handling and reconciliation logic.
- Contributed to monolith decomposition into multiple focused services.
- Implemented Redis caching that reduced API latency by 40%.
- Improved service reliability through idempotent processing and fault-tolerant design patterns.
- Collaborated across engineering and product to move services from design to production.
Related Pages
Connected case pages
Payment orchestration case
Detailed write-up of workflow design, retries, reconciliation, and asynchronous event publication.
Resume index
The top-level index page that connects profile summary, experience, skills, and case pages.
This page is domain context for a past role. My current role is Backend Engineer at Lanzar.