Build a following feed with current access checks

Application background

A reader opens a feed of posts from people they follow. The application gathers candidate post IDs and displays the posts the reader may currently see. Preparing those candidates ahead of time makes the feed faster.

That preparation is not enough on its own. A creator can delete a post or make it private after its ID has been placed in followers' feeds. A celebrity with millions of followers also makes copying every new post ID expensive.

Example walkthrough

A feed entry is a pointer to a possible result. It is not a permanent permission to read the post.

Sizing that affects this decision

At 120,000 feed requests/s with 30 items per page, the service may need to consider 3.6 million candidate items/s. Separately, one celebrity post can target ten million follower feeds. Read-side checks and publication fan-out are different amounts of work, so size them separately.

These are exercise assumptions. The estimation reference explains the units and approximations. They do not establish the local demo's measured capacity.

Your assignment

Deliver: Build a following feed, including a strategy for authors with very large audiences. Check current deletion and privacy rules before displaying candidate posts.

Required behavior: GET /feed returns up to 30 currently authorized posts using a stable cursor. New eligible posts should appear within ten seconds under normal load. The precomputed feed stores candidate post IDs, rather than granting access to their content. Post visibility is checked before returning content.

The required first milestone is a working local implementation of the behavior above. The numbered implementation steps define the scope. The cloud architecture is a later extension, not something the starter has already provisioned.

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/social_feed.py

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

"""Local mechanism demonstration for social-feed. No AWS resources are created."""
posts={'p1':{'text':'Team update','public':True},'p2':{'text':'Old private draft','public':False}}
feed=['p2','p1']; deleted={'p3'}
def visible(ids):
    return [posts[i]['text'] for i in ids if i not in deleted and i in posts and posts[i]['public']]
print('Warm feed candidates:',feed); print('Returned content:',visible(feed))
posts['p1']['public']=False
print('After revocation:',visible(feed))

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.

Warm feed candidates: ['p2', 'p1']
Returned content: ['Team update']
After revocation: []

Set up your implementation workspace

Create work/social-feed/ 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. Build a read-time feed first

Query recent posts by followed authors and merge by a deterministic order. Use opaque cursors that preserve ordering across pages. Measure the cost before introducing fan-out. This baseline is also a recovery path when materialization lags.

2. Materialize ordinary-author candidates

Emit post events from an outbox and append idempotent references to follower inboxes. Record fan-out progress and age. Treat deletion as a source version change so late create events cannot resurrect a removed post.

3. Handle celebrities on read

Keep very large-author streams separate and merge them with the reader’s materialized candidates. Choose a threshold from measured fan-out cost and read frequency, not follower count alone. Bound candidate fetches so one empty/private stream cannot cause unbounded refill work.

4. Authorize before returning content

Batch-fetch current post metadata and apply membership, blocks, privacy and deletion rules. Cached candidates may survive. Restricted content must not. Define whether a cursor remains usable when eligibility changes, and tolerate shorter pages rather than leaking an item.

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 hybrid design spends writes for ordinary authors and reads for celebrities. Neither path owns privacy. Current source state decides which content can leave the service.

Provision resources, then connect the application

Use one disposable AWS environment for the cloud exercise. 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

Worked follow-up: Revoke a creator without waiting for every feed copy to disappear

A popular creator has millions of copied feed entries. Deleting every projection first can take minutes or hours. Ranking snapshots solve pagination, but do not authorize serving revoked content.

Revised architecture. Follow the changed responsibility and failure path below. This is a design to implement. The supplied local example does not provision these components.

What to implement. Keep source visibility and creator status authoritative. Before returning feed candidates, filter them using a revocation decision with a stated freshness bound and fail-closed behavior. Repair projections asynchronously. Use a snapshot or ranking version for pagination, but let revocation override that snapshot. Separate fanout workers from cleanup workers and budget both so a removal does not freeze new posts. The cache stores candidates, not an irrevocable permission grant.

Walk through the result. Fetch page one under rank version 12, remove creator C, then fetch page two while cleanup is paused. C must be filtered and pagination must not repeat prior visible posts. Explain that the page may contain fewer items. Hand over the cursor fields, revocation bound and repair-progress metric.

Introduce ranked ordering. Freeze or version enough ranking context to make pagination understandable, then explain how you avoid duplicate posts when new scores arrive between pages.