My journey at Amazon started in the NPS (Non-Payment Suspension) team, which was within the AWS Commerce Platform organization. This organization was responsible for taking care of the commercial operations of AWS, including billing calculations, invoicing customers, collecting payments, etc. Our NPS team in particular was responsible for suspending/terminating AWS accounts that accumulated several unpaid invoices.
However, during the first 3-6 months I had the opportunity to help the Invoicing team with an org-wide project that involved emitting invoices based on the customer’s specific country/region for tax and other legal purposes. This was particularly beneficial because I was able to learn about other teams within the organization, get familiar with their processes and terminologies, while also seeing the project through and deliver value to our customers sooner.
After this project completed, I moved back to the NPS team to work on a new project with the goal of re-architecting the whole AWS Payments organization’s systems. The project was called Business Process Orchestrator, and it was intended to have a central place were we could define and operate the business logic of our organization without engaging with multiple engineering teams and wasting their time. The drivers behind such an ambitious project were the unmanageable operational load on our engineers, the huge amounts of effort that the different teams had to invest every billing cycle (monthly) just to coordinate the generation of invoices, and the constantly appearing issues that came up during each cycle that would cause all sorts of customer pain. In order to solve those issues while making sure that the bureaucratic inertia wouldn’t halt our progress, we designed our system using event-driven architecture, AWS-native components (e.g. Lambda, SNS/SQS, DynamoDB, etc.), existing internal tools/processes and popular programming languages (e.g. Java), and also developed libraries that would ease the onboarding of each team into this system.