Senior Backend Engineer
FlyESim is a digital product platform serving global customers. I came in with no handoff and owned the backend from day one — scoping, proposing, and shipping every piece independently. The work covered the purchasing and financial system, a CI/CD pipeline built from scratch, and an emergency database migration executed under real production pressure. Every decision here had direct consequences on live transactions or production uptime.
CI/CD Pipeline
There was no automated pipeline when I joined. Every deployment was a manual process — error-prone, inconsistent, and a risk every time someone pushed. I identified this as an immediate priority and built it without waiting to be asked.
I built a GitHub Actions workflow covering lint, unit tests, integration tests, build, and deploy. The pipeline runs on every push to the main branch and blocks merges on failure. Deployment went from a manual checklist to a single merge. The team now ships with confidence that a broken build cannot reach production.
Transactional Systems
The bulk purchasing flow required strong consistency across account debits, order creation, and financial calculation. A partial write — a debit without an order, or an order without a recorded commission — would leave accounts in an inconsistent state with no clean recovery path.
I designed the service layer so each operation has a clear transaction boundary: everything inside commits together or nothing does. Retries are idempotent by design. Partial failures are caught at the boundary and surfaced as a clean error rather than silently committed half-state.
The commission and discount engine runs inside the same boundary. Rates are configurable per partner. The calculation logic is fully decoupled from persistence so it can be tested independently and changed without touching the core purchase path.
Emergency Migration
A regional cloud outage left the production database in a state that required a live migration to recover. I scoped the migration, wrote the rollback plan, and executed it under production pressure with real transactions in flight.
The judgment calls here mattered more than the mechanics — what to migrate first, how to sequence the steps to preserve consistency, when to commit and when to roll back. No data was lost. The window was tight and the work had to be right the first time.
Batch Processing
A scheduled bulk operation needed to run reliably without any risk of double-execution or partial application. A naive implementation would leave records in an ambiguous state if interrupted mid-run, requiring manual inspection before it was safe to retry.
I built it as an idempotent batch worker: each record is marked before processing, and the worker checks that marker before acting. Every execution writes an audit log entry regardless of outcome. The job can be rerun safely after any failure without manual cleanup or state inspection.