CloudMart on AWS: keep requests and workers independent

Start with the actual application

CloudMart Order Pipeline uses FastAPI for order requests, PostgreSQL for stored records, Redis for queued work and a separate background worker. Those responsibilities are useful deployment boundaries. The AWS layout in this article is a proposed cloud design based on that project; the verified application workflow is the local implementation and the public browser edition.

Give each process a clear role

The API should validate an order, persist the relevant state and return an understandable response. Processing can take place independently. A slow worker should not silently turn every checkout request into a long-running HTTP operation.

Amazon ECS with AWS Fargate runs containers without requiring you to provision the underlying EC2 hosts. You still define the task’s compute requirements, networking and IAM permissions. For this design, the API and worker would be separate workloads rather than two unrelated processes hidden inside one container.

flowchart LR
    U[Browser] --> L[HTTPS entry point]
    L --> A[FastAPI on ECS]
    A --> D[(PostgreSQL)]
    A --> Q[Redis queue]
    Q --> W[Worker on ECS]
    W --> D

Treat data as a separate lifecycle

An application image is replaceable. An order record is not. PostgreSQL and the queue therefore need explicit persistence, network access rules, backup ownership and restore checks. Moving them to a managed service is a design choice to evaluate, not a reason to skip those requirements.

Fargate tasks use task networking with dedicated network interfaces. A proposed layout would expose the HTTP entry point and keep data services reachable through deliberate network rules. Public ingress, outbound dependency access and database access are different decisions.

Design for a repeated message

An interrupted worker can see the same order again. Before scaling workers, define how a duplicate is recognized and how status transitions remain consistent. A stable order identifier and explicit processing states make the discussion concrete. This is a reliability requirement for a production adaptation; it is not a claim that every failure scenario is already solved by the browser demo.

accepted -> queued -> processing -> completed
                        |
                        +-> failed -> reviewed retry

Verify the handover

• Check that an accepted request produces the expected stored order.
• Pause a worker and confirm the API’s behavior is still understandable.
• Resume processing and inspect the resulting state.
• Re-submit an identifier and verify the agreed duplicate behavior.
• Restore a backup into an isolated environment before relying on it.

The project makes the API–queue–worker relationship visible. A cloud deployment would add region selection, capacity, operational ownership, monitoring and cost review around that relationship.

Explore the CloudMart browser workflow