In modern e-commerce, “working at scale” often means handling tens of millions of real-time transactions, in multiple regions, under strict regulatory and security constraints, and without a single visible glitch for the customer. That is where Sathiya Veluswamy operates with 17 years of experience in software development.
Her field of expertise is scalable web application development in e-commerce. At Amazon, she serves as a Software Development Manager in the Gift Cards organization, where she led the migration of a 25-year-old monolithic platform to a modern, cloud-native Java architecture.
The system now supports 22 marketplaces and 40 languages, handling tens of millions of requests per day with zero downtime during the transition. Before Amazon, she played a key development role in Cisco’s Unified Commerce Experience platform, building a seamless quoting and deal-making interface for global networking product sales. In this conversation, Sathiya talks about re-architecting Amazon’s global gift card system, designing for high availability, the differences between B2B and consumer e-commerce, and how the role of the engineering leader is evolving.
Disclaimer: The views and opinions expressed in this interview are Sathiya’s own and do not represent those of Amazon or Cisco.
Sathiya, to begin, could you walk us through your career journey and your current role at Amazon?
I’ve spent the past 17 years in software development, gradually moving from hands-on engineering to leading large-scale initiatives. Early in my career I focused on building systems myself. Over time, I became more involved in designing platforms and guiding teams through complex transformations.
For the last several years, I’ve been working at Amazon on critical, customer-facing systems where reliability, scale, and customer obsession really are non-negotiable. I currently serve as a Software Development Manager in the Amazon Gift Cards organization, leading teams responsible for the electronic gift card purchase experience.
Our services enable millions of customers around the world to purchase and send digital gift cards seamlessly. We design for security, reliability, and performance, but we also care deeply about the experience being frictionless and delightful. My work spans modernizing legacy platforms, integrating distributed architectures, and building entirely new customer experiences. One of my largest projects was migrating Amazon’s Gift Cards system, which had been in use for 25 years, to a modern service-oriented Java architecture, enabling a 240% increase in daily requests.
What excites me most about my current role is a blend of technical innovation and human connection. I enjoy building robust, scalable systems, mentoring engineers, and fostering a culture of ownership, learning, and innovation.
What key engineering decisions allowed you to migrate the 25-year-old Amazon Gift Cards monolith to a modern architecture?
The key was to apply a deliberate, incremental approach. We started with a deep discovery phase where it was crucial to understand how the legacy system behaved in production, which components were most critical, where coupling was highest, and which services would give us the biggest impact if we migrated them first.
Implementation followed a phased pattern. We broke down functionality into services that we could stand up alongside the monolith. In many cases the new services ran in parallel with the old ones until we were fully confident in their behavior under real traffic. We invested heavily in automated tests, synthetic transactions, and canary deployments. Every release was designed with safe rollback paths.
What were the main technical barriers you encountered during this migration?
The hardest part was doing it at Amazon’s scale, where even small issues can affect a huge number of customers. Balancing the speed of migration with system stability required careful planning and phased execution. The gift card platform is connected to many upstream and downstream systems, such as payments, anti-fraud, fulfillment, accounting, analytics, and more. Maintaining API compatibility and ensuring seamless connections across all dependent systems was critical to preserving the customer experience.
Risk mitigation was also central. We built comprehensive testing pipelines, canary deployments, automated health checks, and robust rollback mechanisms so that if anything unexpected occurred, we could recover instantly without affecting customers. Security and operational standards were maintained at every step.
What changes in the purchase pipeline allowed you to significantly increase daily traffic?
It was the result of a holistic approach to scalability and performance, and it wasn’t just about handling more traffic. One of the biggest challenges was ensuring a consistent and seamless customer experience across multiple marketplaces and languages.
Architecturally, we re-designed critical parts of the purchase pipeline to handle much higher concurrency. Robust real-time monitoring allowed us to see exactly how each component behaved under load.
On the performance side, we focused on end-to-end latency. We streamlined workflows, reduced synchronous dependencies, and tuned data access patterns. The goal was that a customer in Tokyo, Paris, or New York would see the same fast, predictable behavior.
Infrastructure evolution played a major role as well. Automated scaling strategies allowed the system to expand gracefully under peak loads and contract when traffic was lower. In the end, I’m really proud that we maintained 99.99% system availability even during migration.
How did you manage to maintain system availability at such a high level?
It was less about one big decision and more about a set of consistent practices across architecture, operations, and security. From a design perspective, we built redundancy into every critical path. Services run with fault tolerance patterns in place so that individual component failures are isolated. Monitoring and incident response let us track system health in real time, with alerts for both infrastructure and application-level signals.
Operational excellence means testing and review. Deployments are gradually rolled out, and maintenance is scheduled and executed to avoid user disruption. Post-incident reviews feed improvements back into our processes. Risk management and security supported by tested backups, well-documented recovery procedures, and regularly exercise disaster-recovery scenarios.
At Cisco, you worked on the Unified Commerce Experience (UCE), a B2B platform for partners. What are the fundamental differences between building large-scale B2B commerce systems and designing consumer-facing e-commerce platforms?
In short, B2B systems scale in complexity, while consumer systems scale in concurrency. Both require strong engineering practices, but the trade-offs and design choices differ significantly.
In a B2B platform like Cisco’s UCE, complexity comes from customer diversity. Partners may have unique pricing structures, contract terms, approval workflows, and inventory rules. The platform must be highly configurable, support complex business logic, and integrate with enterprise systems like ERP, CRM, and supply-chain tools. Performance matters, but flexibility and correctness across many different scenarios are often the primary drivers.
Consumer-facing platforms, such as Amazon’s gift card and retail systems, prioritize scale and speed. Millions of customers may be interacting at the same time, so low latency and fault tolerance are crucial. The business logic is more standardized, but the platform must handle extreme traffic, operate reliably across devices and geographies, and support continuous experimentation and deployment.
Many companies are now moving from monoliths to cloud-native and microservice architectures. Do you expect e-commerce architectures to continue toward greater modularity, or is a new paradigm emerging?
Modularity will remain central, but the way we apply it is evolving. Microservices and cloud-native architectures have already given e-commerce platforms the ability to scale independently, deploy faster, and isolate failures, which are essential for global e-commerce. Intelligent, event-driven architectures powered by AI will enable systems to proactively adjust capacity, optimize workflows, and even anticipate customer needs.
And, of course, privacy and security remain central. Distributed, modular systems introduce more APIs and data flows, so strong encryption, access control, monitoring, and compliance with regulations like GDPR and CCPA are critical to maintaining trust.
How do you see the role of an engineering leader in e-commerce evolving? Will the focus be more on architecture, team management, or the ethical aspects of technology?
I believe the role of an engineering leader in e-commerce will continue to evolve toward a balance of all three. Team management and culture will become even more important. Engineering leaders must mentor and empower teams, foster ownership, encourage innovation, and create environments where engineers can make smart trade-offs confidently. The ethical dimension of technology is also becoming a core part of the role. Decisions about data usage, personalization, automation, and AI have real implications for privacy, fairness, and user trust. Engineering leaders are increasingly responsible for ensuring that the systems they build are not only efficient and scalable but also responsible and aligned with the organization’s values.
The future engineering leader in e-commerce will be a hybrid: part architect, part operator, part people leader, and part ethical steward. The combination is what enables teams to build systems that are powerful, trustworthy, and truly customer-focused.
