About Me
Backend, Cloud and
Data Platform engineer.
Systems thinker.
Occasional writer.
Background.
In my role as a Backend Engineer (Data Platform), I build reliable backend systems and data pipelines that handle real-time production traffic.
My day-to-day work involves native cloud development on AWS, serverless data engineering, and developing robust backend services. Most recently, I have been working on a platform that processes 2 million+ daily transactions and have designed ETL and ELT pipelines that move terabytes of data across Lambda, Kinesis Firehose, S3, Glue, and Athena. My work has ranged from ingesting raw events at the edge to building clean, schema-governed analytics layers that create robust reporting structures, which analytics and product teams can depend on.
Even though I currently contribute to an IC role, I have always been deeply interested in Software Architecture. Over time, I have realized that while building and maintaining production systems is important, the most crucial skill is being able to design them correctly.
I have developed the ability to think about costs, failure cases, monitoring, and trade-offs early on, because experience has taught me that those are usually the things that get harder to fix as time goes by. While there is always a balance between cost, performance, and complexity, I prefer that those decisions are made visible rather than leaving them implicit within the system.
Right now, I am focused on serverless data infrastructure on AWS and working with data lakehouse-style patterns. I enjoy working on the layer that converts raw data to usable reporting systems. Longer term, I am moving toward solutions architecture - working closer to system-level decisions where both business and technical constraints need to be considered together.
Where I've built.
Engineering cloud-native data workflows and reporting infrastructure for a high-volume advertising platform serving 350+ enterprise customers and processing 2M+ transactions daily.
- Designed and built Lambda-based ETL pipelines that extract, transform, and deliver structured reports from terabytes of multi-source data across 80+ customer accounts.
- Owned end-to-end delivery of 20+ customer change requests for reporting workflows, maintaining a 100% closure rate with an average turnaround under 48 hours.
- Improved processing reliability and data consistency for reporting workflows through AWS-native observability improvements.
- Contributed to the development and reliability of the Arity Advertising Platform - a cloud-native product that ingests and processes advertising attribution data at scale across connected-vehicle data streams.
- Collaborated directly with cross-regional stakeholders across the US and Guatemala on feature design, release coordination, and production issue resolution.
Led architecture and delivery for backend and data engineering initiatives, including AWS migration and reporting pipeline modernization.
- Led a cross-functional team of 6 engineers across India, US, and China while aligning with US and Canada stakeholders on architecture decisions.
- Built and optimised AWS-based reporting pipelines using Firehose, S3, Lambda, and Athena to improve data accessibility and processing efficiency.
- Developed ingestion and processing services with C# and PostgreSQL for near real-time instrument data handling.
- Migrated legacy desktop workflows to AWS cloud architecture, improving maintainability and release velocity.
Built and maintained data-intensive backend services while improving reliability and maintainability of legacy systems.
- Maintained and optimised C#, .NET, and SQL-based backend systems to improve performance and reliability.
- Refactored legacy architecture into modular components to simplify future development.
- Resolved 60+ critical production issues and helped reduce average resolution time by 30%.
How I think about systems.
A few principles that show up in how I design and how I operate - not a philosophy manifesto, just what I've found actually matters.
The interesting questions are: what happens when this Lambda times out? What happens when the upstream schema changes without warning? Systems designed around failure modes tend to be simpler than systems that try to prevent failure.
I've learned to treat operational complexity the same way I treat cloud cost - something to be measured, minimised, and explained. The most elegant solution is rarely the one that requires the most operational knowledge to run.
Every architecture decision trades something - cost, latency, consistency, simplicity. I try to make those trade-offs explicit and documented, so the next person (or future me) isn't reverse-engineering intent from code.
I've seen too many systems over-engineered for scale that never arrived. Start with the simplest thing that could work; build the instrumentation to know when it stops working; then scale the bottleneck, not the whole system.
How I work with people.
-
→Cross-functional global teams. Led engineering across India and the UK. Learned that clear written communication and asynchronous decision records matter more than synchronous stand-ups when you're spanning time zones.
-
→Technical decision ownership. Comfortable taking ownership of architecture decisions, writing up trade-offs for stakeholder review, and defending a position while staying open to being wrong. ADRs, not debates in Slack.
-
→Stakeholder alignment. Have regularly translated technical constraints into business language - and vice versa. Know that a good engineering conversation with a non-engineer ends with shared understanding, not just a nod.
-
→Mentorship. Prefer creating engineers who can work independently over engineers who wait for answers. Reviews that explain the why. Pairing on hard problems rather than just reviewing the solution.