Write a data-platform policy from concrete decisions

Application background

An engineering organization repeatedly chooses storage for different products. Billing needs correct account updates, inventory needs safe reservations, event processing needs to replay input, and analytics needs to query large histories. One database choice is unlikely to suit all those needs equally.

Instead of beginning with a preferred technology, examine several real or clearly constructed decisions and record which requirements drove each one. Turn that evidence into a short policy that helps the next team make a choice.

A decision policy states which facts lead to which recommendation. Its value is helping a future decision, not making every team use the same service name.

Your assignment

Deliver: Write a short data-platform decision policy grounded in five concrete cases. Show how it helps decide a new case, and identify when a team should request an exception.

Required behavior: The memo cites the constructed decision records, states the shared constraint, proposes a default and names evidence-based exceptions. It includes operating ownership and a review trigger when relevant capabilities or requirements change.

The primary deliverable is the report or operational procedure named above, backed by a reproducible local demonstration. Build the smallest supporting code needed to make that evidence visible.

Get the code and run the supplied example

The code is in the public junior-to-staff repository. Install Git and Python 3.12+. No AWS account or Python packages are required for this first run. If you already have a checkout, use it and skip cloning.

git clone https://github.com/Soulful-Iris/junior-to-staff.git
cd junior-to-staff
python3 examples/architecture-starts/the_strategy_you_found_rather_than_invented.py

Supplied file: examples/architecture-starts/the_strategy_you_found_rather_than_invented.py. You can also read or download the source here (download file, source below).

"""Local mechanism demonstration for the-strategy-you-found-rather-than-invented. No AWS resources are created."""
from collections import Counter
records=[('D1','transactions'),('D2','transactions'),('D3','transactions'),('D4','replay'),('D5','reporting')]
print('Constructed evidence:',records)
print('Shared requirements:',dict(Counter(kind for _,kind in records)))
print('Default: transactional store; exceptions: independently replayable events and isolated analytics.')

This program is a mechanism demonstration: it runs the small scenario in one process and prints the result. It is not an HTTP service, a complete application, or an AWS deployment. A successful run demonstrates this mechanism only. It does not establish the workload or failure guarantees of the application you will build.

Example output from the supplied run:

Generated IDs and timestamps may differ. Compare the state transitions and outcomes.

Constructed evidence: [('D1', 'transactions'), ('D2', 'transactions'), ('D3', 'transactions'), ('D4', 'replay'), ('D5', 'reporting')]
Shared requirements: {'transactions': 3, 'replay': 1, 'reporting': 1}
Default: transactional store; exceptions: independently replayable events and isolated analytics.

Set up your implementation workspace

Create work/the-strategy-you-found-rather-than-invented/ in your checkout (or use a separate repository). Copy the supplied mechanism into that directory as mechanism.py, then extract its state transitions into functions you can call from your implementation. The record and module names below describe what you must implement. They are not a promise that files with those names already exist. Keep a README.md beside your implementation with its exact run commands and observed results.

Local components and state to implement

This table names the records, interfaces or decision inputs for your deliverable. Unless a name is explicitly linked to supplied source above, it is something you create. Implement the local state transitions first, then connect the HTTP, storage or worker boundaries required by the steps.

Implement the assignment

1. Write the five source decisions

Record D1 billing atomicity, D2 inventory ownership, D3 permission/audit transaction, D4 independently replayable events and D5 reporting isolation. Include rejected options and their actual constraint, not merely which technology the team preferred.

2. Extract the common default

Propose PostgreSQL for transactional application records when its measured capacity and access patterns fit. Explain existing expertise, backup/restore and operating cost. A count of three choices is a clue. The transaction requirement is the reason.

3. State explicit exceptions

For D4, retain an event log/archive with replay identity and retention. For D5, isolate expensive analytical scans through a projection or warehouse. Name ownership, lag and reconciliation costs introduced by each exception.

4. Make the next decision easier

Give teams a short decision path: required guarantee, existing default fit, measured gap, smallest exception and owner. Revisit when a named workload or service capability changes. Avoid universal slogans that erase the concrete replay and reporting counterexamples.

Demonstrate the completed local result

Handoff: In your implementation README, include the start command, one successful operation, the failure case above and the resulting stored state or decision. State which dependencies are simulated. Someone with a fresh checkout should be able to reproduce this without your chat history.

Workload assumptions and capacity decisions

These are constructed exercise assumptions. The stated workload is a design target. The local demonstration does not establish that throughput. Use the estimation constants to check units before choosing capacity.

Map the local implementation to AWS

Deployment status: local only. Running the supplied command creates no AWS resources and configures no cloud connections. The diagram is a proposed deployment of the completed application. Each box needs either a deployed runtime, a provisioned service or an explicitly external dependency.

Read the diagram by following the arrows from the entry point: application code accepts the request or event, the state owner commits it, and any worker produces the later result. The table ties those roles to code and adapter work. Multiple boxes do not imply multiple Python files already exist.

The diagram shows one concrete composition that preserves the three different workload needs. It is evidence for the policy discussion, not a claim that every team should deploy the whole stack.

Provision resources, then connect the application

For this decision project, provision resources only if a bounded implementation spike needs them. The diagram is also usable as the concrete option being evaluated. Put the named resources in infra/template.yaml or your existing IaC tool, pass resource IDs through configuration, and scope each runtime role to its own tables, buckets and queues. The diagram is a design to implement. It is not a claim that these resources have been deployed. Record the commands you used to deploy and remove the exercise resources.

For concrete provisioning commands, configuration wiring and cleanup, use the AWS foundation guide. It includes a deployable table/queue/object-storage foundation and explains which application and service adapters you still implement.

A provisioned queue or table does not make the local program use it. Configure resource IDs in the deployed runtime, replace the local adapter, and replay the same successful and failing operation against that runtime. Record the deployed commit and observable result, then remove the disposable resources using your infrastructure tool.

Extend the design after the baseline works

A team requests a new datastore for developer preference alone. Ask for the unmet guarantee or measured operating improvement, then compare it against the additional ownership burden without treating novelty as either sufficient or forbidden.