ExperienceSoftware Development Engineer Intern
Software Development Engineer Intern
Amazon, FBA Inbound Placement Team
May '24 - Aug '24 · 4 months
Case study
Building a Scalable Workload Execution Platform
I worked on a cloud-based platform designed to automate and orchestrate the execution of configurable workloads. It brought together infrastructure as code, serverless compute, workflow orchestration, configuration management, and parallel processing - and it is where a lot of distributed-systems ideas I had only read about turned into something I had actually helped build.
Context
This is a technical case study of that work, written at a deliberately high level. Everything here is about engineering concepts and my own experience - the design patterns, the AWS services, the tradeoffs, and what I took away. None of it describes Amazon's internal systems, names, data, or implementation; where a detail would only make sense as internal documentation, I have generalized it.
At its core, the platform ran a collection of independent workloads that changes over time, and it ran them from configuration rather than from hand-written workflow code.
The problem
The platform had to support a collection of configurable workloads that is not fixed - workloads get added, retired, enabled, disabled, and rescheduled independently of one another. The execution workflow could not be redesigned by hand every time that collection changed.
Conceptually, the platform needed to:
- maintain workload configuration
- determine which workloads are eligible to execute
- account for enablement and configuration state
- account for scheduling criteria
- orchestrate the eligible workloads
- process each workload independently
- stay scalable as the collection grows
When the set of workloads is dynamic, embedding each one directly into the execution workflow creates unnecessary coupling. Every change to the workload set becomes a change to the workflow, and the workflow slowly turns into a list of special cases. A more flexible approach is to separate the workload configuration from the mechanism responsible for executing it.
That is a general design principle - not a claim about a specific internal decision.
The core idea
The architecture is configuration-driven. Workloads are described as configuration; a separate execution engine operates over whatever that configuration currently says. Adding or changing a workload is a configuration change, not a workflow change.
What should run?
What is eligible right now?
How should it run?
Separating the description of workloads from the machinery that runs them lets the execution system work over a collection of configured workloads, instead of needing a bespoke workflow for each one.
High-level architecture
At a conceptual level, the flow looks like this - a high-level model, not a resource topology.
Configuration - AWS AppConfig
AWS AppConfig manages the workload configuration as its own concern, separate from the execution workflow. Conceptually, that configuration can describe things like a workload's identity, whether it is enabled, when it is eligible to run, and settings that affect how it executes.
Keeping configuration separate buys a few things:
- configuration can evolve without touching or redeploying execution logic
- the execution engine does not have to encode knowledge of every workload
- operational changes are separated from application changes
- the platform stays extensible - a new workload is a new configuration entry, not new workflow code
Workload selection
A processing component reads the configured workloads and works out which ones should take part in the current execution cycle. I worked with the logic responsible for evaluating configured workloads and determining which ones are eligible right now.
Eligibility comes down to general criteria - whether a workload is enabled, whether its configured scheduling criteria are currently satisfied, and whether it is otherwise in a state where it should run.
Workflow orchestration - AWS Step Functions
The eligible set is handed to AWS Step Functions, which coordinates execution as an explicit workflow rather than one large block of application code. Individual processing stages become individual steps, with the transitions between them modeled directly.
Within that workflow, a Map-style pattern applies a common execution model across the collection of eligible workloads. Because each workload is independently executable, the same processing shape runs over all of them, in parallel, without the workflow needing to know anything specific about any one of them.
Modeling it this way keeps responsibilities separated - orchestration in the workflow, work in the tasks - makes each workload's execution easy to reason about on its own, and lets the platform scale by adding work rather than redesigning the flow.
Serverless processing - AWS Lambda
AWS Lambda provides the processing components inside the workflow. Different responsibilities in the flow are separate functions rather than one monolithic service.
- each processing step is an independent, separately deployable unit
- functions are driven by the workflow rather than by long-running infrastructure
- there is no server fleet to manage or scale by hand
- Lambda integrates cleanly as a Step Functions task target
Why parallel processing mattered
Treating the whole collection as one indivisible operation would mean the slowest or most complex workload sets the pace for everything, and a single failure is a failure of the batch. Because the workloads are independent, the architecture runs each one through a common processing model on its own.
What that gives you:
- lower coupling between workloads
- independent processing and failure boundaries
- room to add workloads without structural change
- each workload can be reasoned about in isolation
Infrastructure as code - AWS CDK
AWS CDK defines the platform's infrastructure in code. The cloud resources, how they are composed, and the dependencies between them live in the same codebase as the application - version-controlled and deployed the same way.
Working in CDK meant treating infrastructure as software: it needs structure, naming, and review like anything else, and it is designed alongside the application architecture rather than as a separate concern. It also makes deployments consistent and reproducible instead of assembled by hand.
How the pieces fit together
None of these services is doing anything exotic on its own. The point is how they combine into a configuration-driven execution model.
defines the cloud infrastructure
holds the workload configuration
evaluates which workloads are eligible
orchestrates execution of the eligible set
runs a common model over independent workloads
carries out each workload's processing
Change the configuration and the same machinery does something different - with no code change.
My contribution
This was a team system. My focus was on a few layers of it, and on understanding how they had to fit together.
- I contributed to the design and implementation of the cloud infrastructure and the execution workflow.
- I worked with AWS CDK to define infrastructure as code.
- I worked with Step Functions to implement workflow orchestration.
- I contributed to Lambda-based processing components.
- I worked on configuration-driven workload selection.
- I worked with Map-based processing to support independent workload execution.
- I worked across the infrastructure, configuration, orchestration, and serverless-processing layers.
The value for me was less in any single piece and more in seeing how each one had to agree with the others.
Engineering challenges
Keeping configuration separate from execution
Avoiding a workflow that slowly accumulates one branch per workload.
Designing for independent processing
Making every workload fit a single common execution model.
Orchestrating distributed processing
Using Step Functions to coordinate serverless components explicitly, instead of implicitly through application code.
Managing infrastructure consistently
Representing infrastructure as code rather than manual setup, so environments stay reproducible.
Designing for extensibility
Letting the set of workloads change without changing the execution model.
Lessons learned
Infrastructure is part of the application
CDK taught me to give infrastructure the same structure and care as application code.
Orchestration can simplify distributed systems
Step Functions made workflow coordination explicit instead of buried in application logic.
Configuration reduces coupling
Separating workload definitions from execution logic makes a system far more flexible.
Parallelism should follow natural workload boundaries
When units of work are genuinely independent, the workflow can model that directly.
Managed services change the questions you ask
With serverless, the focus moves off servers and onto interfaces, workflows, state, failure boundaries, and scale.
Technology stack
AWS CDK
Infrastructure as code
AWS Step Functions
Workflow orchestration
AWS Lambda
Serverless processing
AWS AppConfig
Configuration management
Closing reflection
This is one of the experiences I point to when I think about how I have grown as an engineer. Wiring together CDK, Lambda, Step Functions, and configuration management - and watching a set of individual cloud services behave as one distributed system - gave me a much clearer sense of how to design something that is not just working, but maintainable, extensible, and able to scale. I came out of it thinking in terms of boundaries, state, and failure modes, not just features.
© 2026 Gaurav Divecha. All rights reserved.