Design a Wordle-Style Game for Millions

Design a scalable Wordle-style game architecture and explain its trade-offs.

Introduction

30 Second Summary

A daily word puzzle feels effortless when the page loads quickly at midnight. That simple experience gets harder when millions of people arrive together or switch devices.

In this project, you will create a system design board in Excalidraw that evolves a static browser game into a backend for millions of daily players. You will use visible failures plus capacity estimation to justify every new component.

What You'll Build

Your finished board will support a five-minute demo where a page load follows the static path before a guess submission crosses the trusted backend.

By the end of this project, you'll have:

A before-and-after architecture that shows a static game becoming a secure backend only after answer secrecy plus cross-device progress demand it.
A capacity card that turns ten million daily players into concrete average traffic, peak traffic, daily writes, and dynamic concurrency numbers.
A five-minute interview walkthrough where you trace request arrows while defending API contracts, data access, cache boundaries, and recovery paths.
Secret Mission: Create an anonymous-only variant by removing Amazon Cognito plus persistent player progress while keeping server-side answer validation.

Are there any prerequisites?

Basic familiarity with common system components is enough because each decision is explained as you draw. A browser is all you need because this project creates no AWS resources.

Before We Start

Before any boxes reach the canvas, commit to the problem you are solving. Every component you add should answer a demonstrated requirement, scale limit, or failure mode.

Set Up Excalidraw and Your Diagram Key

Your design will grow across several steps. A reusable visual language keeps every new component easy to interpret.

Excalidraw gives you an editable canvas for developing that visual language. In this step, you will prepare the canvas for the architecture decisions ahead.

In this step, get ready to:

Create a labeled browser component in Excalidraw.
Define a reusable color legend for the architecture.
Confirm that the saved board remains editable after reopening.

Open Excalidraw and draw the browser

The first rectangle represents the player’s browser. This gives every later request flow a clear starting point.

Open https://excalidraw.com in a new browser tab.

You will see an editable canvas without creating an account.

Choose the rectangle tool by pressing R.
Draw a rectangle near the left side of the canvas.
Start its label by pressing Enter.
Type Player Browser.
Finish the label by pressing Esc.

Good start. Your canvas now has the player-facing component that anchors the rest of the design.

Canvas Not Loading?

Confirm that the address bar shows https://excalidraw.com.
Reload the browser tab if the canvas remains blank.

Help me get the Excalidraw canvas loading.

Build the diagram key and test flow

A color legend lets each component reveal its role before you read the label. The same colors will keep later architecture changes consistent.

Create a text element labeled blue = user/delivery in an empty area of the canvas.
Set that text element to blue using the styling controls.
Create a text element labeled green = compute below the blue entry.
Set that text element to green using the styling controls.
Create a text element labeled purple = data below the green entry.
Set that text element to purple using the styling controls.

Your first three entries now separate delivery, compute, and data at a glance.

Create a text element labeled orange = asynchronous work below the purple entry.
Set that text element to orange using the styling controls.
Create a text element labeled red = risks or failed requirements below the orange entry.
Set that text element to red using the styling controls.

The temporary flow gives you a quick way to practise adding another component. It also confirms that you can connect components with directional arrows.

Choose the rectangle tool by pressing R.
Draw a temporary rectangle to the right of Player Browser.
Start its label by pressing Enter.
Type Test Flow.
Finish the label by pressing Esc.
Select the arrow tool from the top toolbar.
Draw an arrow from Player Browser to Test Flow.

Your canvas now shows a complete test flow beside a five-color architecture key.

Save and reopen the board

An editable .excalidraw file preserves the shapes, labels, colors, and connectors on your board. Reopening that file proves you can continue editing the design later.

Select the save icon.

✔️ I see a save dialog

Your browser supports choosing the filename before saving.

Enter wordle-system-design.excalidraw as the filename.
Confirm the file location to complete the save.

ⓧ The file downloads immediately

Your browser uses the download fallback for editable Excalidraw files.

Locate the downloaded editable file in Downloads.
Rename the file to wordle-system-design.excalidraw.

Your editable board is now stored locally. Before you reopen it, picture the shapes, labels, and colors you expect to return.

Return to the Excalidraw browser tab.
Drag wordle-system-design.excalidraw from Downloads onto the canvas.

You should see the Player Browser rectangle, the Test Flow box, the connecting arrow, and all five legend entries. Your reopened board remains editable.

Board Not Reopening Correctly?

Confirm that the filename ends with .excalidraw.
Use the editable file downloaded through the save icon.
Save the board again if your latest labels or colors are missing.

Help me reopen my editable Excalidraw board.

✔️ My reopened board matches

Your saved board has the browser component, test flow, connecting arrow, and complete color legend.

ⓧ I want to double check the board

Compare your reopened board with this artifact checklist.

The board contains a rectangle labeled Player Browser.
The board contains a temporary box labeled Test Flow.
An arrow points from Player Browser to Test Flow.
The legend defines blue as user and delivery components.
The legend defines green as compute.
The legend defines purple as data.
The legend defines orange as asynchronous work.
The legend defines red as risks or failed requirements.
The editable file is saved as wordle-system-design.excalidraw.

Your visual language is ready. Next, you will use it to draw the static game and expose the requirements that this simple design cannot satisfy.

Draw the Static Game and Expose Its Limits

Your reopened Excalidraw canvas already has a reusable diagram key. It also has a test flow that proves you can connect components.

The static design is the correct simple starting point. Testing it against stronger requirements reveals when backend components become necessary.

In this step, get ready to:

Capture the game's product requirements.
Draw the static game delivery path.
Expose the design limits through requirement tracing.

Capture the product requirements

Requirements keep the architecture anchored to what the product must do. Each later component must answer one of these lines.

Choose an empty area near the top of your canvas.
Press R to select a rectangle.
Draw a large rectangle for the requirements card.
Press Enter to add text to the card.
Enter daily puzzle, fast global page load, answer secrecy, millions of daily players, cross-device progress, player statistics, and non-blocking analytics as seven separate lines.
Press Esc to finish the card.

You should see all seven requirements grouped inside one card. This card is now the test that every architecture version must pass.

Draw the static delivery path

A static architecture can serve the game without dynamic compute.

Amazon S3 stores the browser assets. Amazon CloudFront delivers those assets closer to players.

Return to the existing Player Browser box from earlier.
Press R to select a rectangle.
Draw a rectangle to the right of Player Browser.
Press Enter to label the new rectangle.
Type Amazon CloudFront.
Press Esc to finish the label.
Apply the blue style from your diagram key to Amazon CloudFront.

You should now see the delivery component beside the browser.

Press R to select another rectangle.
Draw the rectangle to the right of Amazon CloudFront.
Press Enter to label the new rectangle.
Type Amazon S3.
Press Esc to finish the label.
Apply the purple style from your diagram key to Amazon S3.

The three components now form the structure of the static game.

Connect Player Browser to Amazon CloudFront with an arrow using the method you practiced on Test Flow.
Connect Amazon CloudFront to Amazon S3 with another arrow.
Add game logic + local progress inside or beneath Player Browser.
Add HTML, CSS, JavaScript, images inside or beneath Amazon S3.

Good progress. Your first working architecture is now visible. The browser can receive every asset it needs to run the game.

Arrows or labels out of place?

Press Esc to leave text editing before repositioning a component.
Reconnect any arrow that ends beside a box instead of touching its edge.
Compare each label with the exact text above if the path is difficult to follow.

Ask for help with the canvas layout: Why are my Excalidraw arrows or labels moving unexpectedly?

Trace the requirements until the design fails

A requirement trace follows data or state through the architecture. The trace reveals whether the current boxes can satisfy a specific product promise.

Before the first trace, consider whether the static path can satisfy every requirement.

Start with the answer stored in the downloaded JavaScript assets.
Follow those assets from Amazon S3 through Amazon CloudFront to Player Browser.

Your trace ends with downloaded JavaScript inside the browser. The answer is therefore available to the client.

Draw a small rectangle beside Player Browser.
Label the rectangle Answer exposed to client.
Apply the red style from your diagram key to the failure marker.

The first failed requirement is now visible beside the path that causes it.

Before the second trace, consider where another device could retrieve progress stored only in this browser.

Start with the game logic + local progress annotation.
Trace the progress beyond Player Browser.

The trace stops inside the original browser. A second device has no shared location from which to retrieve that progress.

Draw another small rectangle beside Player Browser.
Label the rectangle Progress trapped on one device.
Apply the red style from your diagram key to the second failure marker.

Why keep the failures visible?

The red markers preserve the evidence behind future architecture decisions. Every new component must resolve a demonstrated requirement or scaling pressure.

The static path still handles page delivery. Its visible limits now explain why the design must evolve.

Before the final check, predict whether tracing the visible path now explains both failures without a backend.

Trace the static path from Player Browser through Amazon CloudFront to Amazon S3.
Point to Answer exposed to client after tracing the downloaded game assets.
Point to Progress trapped on one device after tracing local progress.
Keep both red failure markers on the canvas.
Leave backend components off this version of the design.

You should see the full static delivery path plus two red failure markers. The board now proves that the simple design works for delivery but fails answer secrecy and cross-device progress.

✔️ My board shows both limits

You have a working static architecture with visible evidence for why it must evolve.

ⓧ I'd like to double check my board

Confirm the diagram key remains visible.
Confirm the original Player Browser plus Test Flow remain visible.
Confirm the requirements card lists all seven product requirements.
Confirm the path reads Player Browser to Amazon CloudFront to Amazon S3.
Confirm Amazon S3 shows HTML, CSS, JavaScript, images.
Confirm Player Browser shows game logic + local progress.
Confirm one red marker reads Answer exposed to client.
Confirm the other red marker reads Progress trapped on one device.

The simple game path is now proven incomplete. Next, you'll quantify what happens when millions of players arrive around midnight.

Quantify the Midnight Spike

Your Excalidraw board now shows a working static delivery path. Its two red markers expose the limits of that design.

The downloaded game reveals the answer. Device-local progress cannot follow the player.

Millions of players is too vague to design against. Explicit assumptions turn the regional midnight release into measurable traffic pressure.

In this step, get ready to:

Define transparent assumptions for the regional midnight spike.
Turn those assumptions into a capacity card.
Split public traffic from private dynamic traffic.

Add the scenario assumptions

Capacity estimation starts with explicit inputs. Calling them assumptions prevents invented precision.

Choose the rectangle tool by pressing R.
Draw a wide card beside the existing requirements card.
Label the card Scenario assumptions, not measured Wordle traffic.
Add 10,000,000 daily players to the card.
Add 4 guess submissions per player to the card.
Add 20% of players active in the hottest regional 10-minute window to the card.
Add 1 page load per active player to the card.
Add 0.2 seconds average dynamic request duration to the card.

You have given the spike an honest foundation by labeling every input as an assumption.

Calculate the traffic pressure

Average traffic describes the full day. Peak traffic describes the hottest regional window.

Dynamic concurrency estimates simultaneous in-flight work. It combines the peak request rate with average request duration.

Draw a second card beside the scenario-assumptions card.
Add Daily guess writes: 10,000,000 x 4 = 40,000,000 to the calculation card.
Add Average guess RPS: 40,000,000 / 86,400 ≈ 463 to the calculation card.
Add Peak guess RPS: 10,000,000 x 0.20 x 4 / 600 ≈ 13,333 to the calculation card.
Add Peak page RPS: 10,000,000 x 0.20 / 600 ≈ 3,333 to the calculation card.
Add Peak dynamic concurrency: 13,333 x 0.2 ≈ 2,667 to the calculation card.

How the Math Maps to Pressure

Daily guess writes estimate how often gameplay changes stored state. Average guess RPS spreads those writes across the full day.

Peak guess RPS compresses activity into the hottest window. Peak page RPS models the page-load burst during that window.

Peak dynamic concurrency estimates how many dynamic requests are in flight at the same time. That result becomes a capacity target to validate before deployment.

Split cacheable and private traffic

A shared cache can serve public page content to many players. Amazon CloudFront receives that reusable branch in your diagram.

Private guesses change player state. They need a trusted boundary that remains blank until the requirements justify specific components.

Draw a blank rectangle beside the calculation card.
Label the rectangle Backend needed.
Draw an arrow from the spike calculations toward the existing Amazon CloudFront box.
Label that arrow cacheable page and public puzzle metadata.
Draw a second arrow from the spike calculations toward Backend needed.
Label the second arrow private guess submissions and progress.
Add validate quotas + load test beside the concurrency result.

Why Leave the Backend Blank?

The boundary captures the work that cannot use a shared cache. Keeping it blank preserves the problem-first sequence.

The next design step can justify each component against secrecy requirements or measured traffic pressure.

Update wordle-system-design.excalidraw by selecting the save icon.

Before you recalculate the card, which peak do you expect to be larger: page loads or guess submissions?

Recalculate each line on the scenario card.
Trace the cacheable path from the spike calculations to Amazon CloudFront.
Trace the private path from the spike calculations to Backend needed.

You should see 40,000,000 daily guess writes. You should also see approximately 463 average guess RPS.

Your regional peak should show approximately 13,333 peak guess RPS. The page path should show approximately 3,333 peak page RPS.

Your dynamic result should show approximately 2,667 peak dynamic concurrency.

The page branch should end at Amazon CloudFront. The private branch should end at the blank backend boundary.

You have turned one vague scale requirement into measurable pressure without removing the static design that already works.

The midnight spike is now measurable. Next, you will use these pressures to justify the backend boundary one component at a time.

Build the Scalable Backend

Your Excalidraw board now turns vague scale into traffic numbers. The static delivery path still serves the simple browser game.

The exposed-answer marker shows that answer secrecy needs a trusted validator. The trapped-progress marker shows that cross-device play needs shared state.

Amazon API Gateway becomes the secure HTTPS entry point for dynamic requests. It also provides throttling at the boundary.

AWS Lambda validates guesses on the server. Amazon DynamoDB stores shared puzzle state and player state.

Amazon Cognito supplies account identity for cross-device access.

In this step, get ready to:

Extend the static design with a trusted dynamic request path.
Define three API contracts plus two data-item shapes.
Set the cache, consistency, and security rules for the backend.

Add the trusted request path

A trusted validation boundary keeps the answer outside the downloaded browser code. Shared storage gives authenticated players one progress record across devices.

The board is becoming dense, so finding clear space may feel fiddly.

Pan to the Backend needed boundary from the previous step.
Draw a green rectangle labeled Amazon API Gateway inside that boundary.

You should see the first trusted entry point beside the private guess and progress path.

Draw a green rectangle labeled AWS Lambda to the right of Amazon API Gateway.
Connect Amazon API Gateway to AWS Lambda with an arrow.

The dynamic path now crosses from request handling into server-side validation.

Draw a purple rectangle labeled Amazon DynamoDB to the right of AWS Lambda.
Connect AWS Lambda to Amazon DynamoDB with an arrow.

You should now see one continuous dynamic path from Amazon API Gateway through AWS Lambda to Amazon DynamoDB.

Draw a blue rectangle labeled Amazon Cognito beside Amazon API Gateway.
Add because: secure HTTPS entry point + throttle boundary beside Amazon API Gateway.

Amazon Cognito now sits beside the entry point where account-linked requests arrive.

Add because: server-side guess validation beside AWS Lambda.
Add because: shared puzzle + player state beside Amazon DynamoDB.

The compute and data boxes now state the requirement that justifies each one.

Add because: account identity + cross-device access beside Amazon Cognito.
Trace the private guess and progress path into Amazon API Gateway.

The blank backend boundary has become a requirement-driven request path. Every new component has a nearby reason for existing.

Why Use Serverless Here?

A serverless design keeps this exercise focused on request flow plus component responsibility. AWS handles the underlying server capacity while the diagram stays centered on requirements.

Long-running containers would add fleet sizing plus scaling-policy decisions. Those concerns would distract from the goal of defending each logical component.

Define the API and data contracts

An API contract defines what a client may request plus what the backend returns. A data-item shape acts as a compact schema for the state behind that contract.

Add a card titled API Contracts beside the dynamic path.
Add GET /v1/puzzles/today as the first contract.

The first contract represents public information needed to open the daily puzzle.

Add a return line containing puzzleId, opensAt, and rules beneath the first contract.
Add never returns answer beneath that return line.

The public response now carries enough information to start the game while the answer stays behind the trusted boundary.

Add POST /v1/puzzles/{puzzleId}/guesses as the second contract.
Add a request line containing guess plus requestId beneath the second contract.

The guess route now shows the player input plus the stable request identifier used for controlled retries.

Add a response line containing result, attemptsUsed, and status beneath the request line.
Add GET /v1/players/me/progress/{puzzleId} as the third contract.

The board now separates guess validation from the route used to resume a game.

Add returns authenticated cross-device progress beneath the third contract.
Add a second card titled DynamoDB Items beside the API contracts.

The API surface is now paired with the data needed to fulfill each request.

Add Puzzle { puzzleId, answer, opensAt, status } to the DynamoDB Items card.
Add PlayerPuzzle { playerId, puzzleId, guesses, attemptsUsed, status, version } below the Puzzle item.

The answer belongs only to the Puzzle item behind AWS Lambda. The PlayerPuzzle item carries the shared progress plus the version used to protect updates.

Trace the answer field from the Puzzle item to AWS Lambda.

Your trace should stop at AWS Lambda. No public response or shared cache contains the answer.

Set the cache, consistency, and security rules

The same data needs different treatment based on who can see it plus how fresh it must be. The matrix makes those decisions visible beside the architecture.

Account-linked routes use authentication. Immediate resume reads prioritize freshness while analytics can accept delay.

Draw a wide card titled Cache, Consistency, Security with one column for each topic.
Fill the Cache column with these decisions:

The Cache column now separates reusable public content from private or freshness-sensitive data.

Fill the Consistency column with these decisions:
Fill the Security column with these decisions:

The completed matrix now states where freshness matters plus where weaker consistency is acceptable. It also keeps private game state outside shared delivery paths.

Select the save icon to update wordle-system-design.excalidraw with the scalable backend.

Before you trace the finished board, consider which path should handle a page load without touching the trusted backend.

Trace one page load from Player Browser through Amazon CloudFront to Amazon S3.
Trace one guess submission from Player Browser through Amazon API Gateway plus AWS Lambda to Amazon DynamoDB.
Point to Amazon Cognito beside Amazon API Gateway to confirm the account-identity path.
Read each backend because-note to confirm that every component answers a requirement or scaling pressure.

The page load stays on the static delivery path. The guess crosses the trusted backend before shared state changes.

That is the core architecture working: fast public delivery remains simple while private gameplay gains validation, identity, shared state, and traffic controls.

Can't Trace Both Paths?

Check that the original arrows still connect Player Browser to Amazon CloudFront plus Amazon S3.
Check that the dynamic arrows connect Amazon API Gateway to AWS Lambda plus Amazon DynamoDB.
Move overlapping cards apart until both paths remain visible.

Ask for help tracing the static and dynamic paths on my system design board.

Your scalable backend now exists for explicit reasons instead of filling the board with generic services. Next, you will test how the design behaves when dependencies slow down or stop.

Add Failure Paths and Practice the Narrative

Your Excalidraw board now connects a fast static delivery path to a trusted gameplay backend. Every box already has a requirement or scaling pressure behind it.

The design still assumes every dynamic dependency stays healthy. A stalled analytics worker can delay a guess if it sits directly on the response path.

This step moves optional analytics behind Amazon SQS. It uses Amazon CloudWatch to expose failures.

You will finish by practicing a five-minute story that follows requirements before technologies.

In this step, get ready to:

Expose the direct analytics dependency.
Add queued analytics plus monitoring.
Map recovery behavior before practicing the design narrative.

Expose the direct analytics failure

The guess response is player-facing work. Analytics is optional work that can finish later.

Locate the AWS Lambda box on the existing canvas.
Create an Analytics Worker box beside AWS Lambda.
Draw a direct arrow from AWS Lambda to Analytics Worker.

Before you trace the new arrow, consider whether the guess response can finish while the worker is stalled.

Trace one guess submission through the direct analytics dependency.

Your trace stops at the stalled worker. Optional analytics now delays the player-facing guess response.

Add a red marker labeled slow analytics delays guesses beside the direct arrow.

The red marker preserves the failed design as a visible comparison. That shortfall gives the next component a precise job.

Amazon SQS is a durable queue for decoupling distributed components. It gives analytics a buffer outside the guess-response path.

Create an Amazon SQS box in the gap from AWS Lambda to Analytics Worker.
Draw an arrow from AWS Lambda to Amazon SQS.

You can now see a buffering boundary between gameplay and analytics.

Draw an arrow from Amazon SQS to Analytics Worker.
Add the label idempotent to Analytics Worker.

Before you trace the queued path, consider where the guess response can stop waiting for analytics.

Trace a guess event from AWS Lambda into Amazon SQS.

That is the critical path protected. AWS Lambda can finish guess validation while analytics waits safely in Amazon SQS.

Why Does Idempotency Matter?

Standard Amazon SQS queues can deliver a message more than once. Idempotency lets the worker handle a repeated event without duplicating the analytics result.

The worker can process a buffered backlog safely after an outage.

Save wordle-system-design.excalidraw by selecting the save icon.

Are the Analytics Paths Hard to Trace?

The old direct path can overlap the queued path. Move the red arrow above the orange Amazon SQS path so each flow stays visible.

Keep every label beside its matching arrow.

Help me arrange the two analytics paths clearly.

Add monitoring and recovery paths

Observability turns silent failures into signals you can investigate. Amazon CloudWatch provides that monitoring layer across the dynamic path.

Create an Amazon CloudWatch box near the dynamic architecture.
Draw a dotted line from Amazon CloudWatch to Amazon API Gateway.

You should see monitoring reach the secure entry point without resembling a request arrow.

Draw a dotted line from Amazon CloudWatch to AWS Lambda.
Draw a dotted line from Amazon CloudWatch to Amazon DynamoDB.

The observability layer now covers compute plus shared gameplay state.

Draw a dotted line from Amazon CloudWatch to Amazon SQS.

You should now see dotted monitoring lines reach API Gateway, Lambda, DynamoDB, and SQS.

What Should CloudWatch Reveal?

Amazon CloudWatch can expose request rates, latency, and error rates across the dynamic architecture. These signals help you identify the dependency that needs attention.

The dotted style separates observation from player traffic.

Graceful degradation defines useful behavior during an outage. A failure card connects each unhealthy dependency to a controlled player experience.

Create a card titled Failure paths beside Amazon CloudWatch.
Add an API throttles row that pairs a controlled retry signal with requestId reuse so a retry does not create duplicate progress.

The first row connects burst protection to predictable retry behavior.

Add a Lambda or DynamoDB is unavailable row covering static-shell availability, a browser-preserved unsent guess, and a later retry without exposing the answer.
Add an Analytics worker stops row covering Amazon SQS buffering, uninterrupted gameplay, and idempotent backlog processing.

The middle rows preserve gameplay during dynamic outages or stalled optional work.

Add a Progress appears stale row covering a strongly consistent base-table read for immediate resume plus investigation of conditional-update failures.
Save wordle-system-design.excalidraw by selecting the save icon.

You have mapped four failure states to concrete recovery behavior. The static shell stays available without moving answer validation back into the browser.

Practice the five-minute narrative

A strong interview narrative follows requirements in the order that they forced changes. Each component enters the story when a failure or scaling pressure justifies it.

The story begins with the existing Amazon CloudFront plus Amazon S3 delivery path. Amazon Cognito enters only when cross-device identity becomes necessary.

Create a card titled Interview cue card.
Add a Requirements line covering the daily puzzle, fast global page load, answer secrecy, millions of daily players, cross-device progress, player statistics, plus non-blocking analytics.

The first cue anchors the architecture in product needs before any service appears.

Add a Static design line covering Player Browser to Amazon CloudFront to Amazon S3.
Add an Exposed limitations line covering Answer exposed to client plus Progress trapped on one device.

These cues show that the static design was useful before stronger requirements exposed its limits.

Add a Capacity estimate line covering 463 average guess RPS, 13,333 peak guess RPS, 3,333 peak page RPS, plus 2,667 peak dynamic concurrency.
Add a Justified evolution line covering Amazon API Gateway, AWS Lambda, Amazon DynamoDB, Amazon Cognito, caching, plus throttling.

The middle cues connect the traffic estimate to a trusted validation boundary plus shared player state.

Add a Failure trade-offs line covering controlled retries, static-shell availability, Amazon SQS buffering, idempotent analytics, plus a strongly consistent resume read.

Your cue card now tells the complete design story in six short beats. The architecture can be explained without reading a catalog of technologies.

Before you rehearse, consider whether every component can be justified without reading its name first.

Cover each component name with a temporary rectangle.
Start a five-minute timer.
Present the six cue lines in requirement order.
Trace the page-load path during the static-design cue.
Trace the guess-submission path during the justified-evolution cue.
Say because after each component name.

You should finish in about five minutes. Your opening should cover the static start plus both visible failures.

Your middle should explain the capacity figures plus every added component. Your ending should explain at least three recovery paths.

Remove the temporary rectangles from the component names.
Save the completed wordle-system-design.excalidraw board by selecting the save icon.

That is the full design story ready for an interview. You can now connect every box to a requirement, scaling pressure, or recovery decision.

Secret mission

Remove What You No Longer Need

Duplicate the final architecture to create an anonymous-only variant. Remove identity plus persistent progress after changing the requirements. Deliver a 60-second defense of why server-side answer validation remains.

Clean Up Your Resources

Your Excalidraw board is a local file with no ongoing cost. Because no AWS resources were deployed, the options below cover keeping, pausing, or deleting the board.

Resources you used:

The editable wordle-system-design.excalidraw board containing your original architecture, anonymous-only variant, capacity estimates, failure paths, and interview cue cards.

Keep everything running

No action needed. Choose this if you want to keep practising your architecture explanation or extend the design.

Keep wordle-system-design.excalidraw as the editable source for both architecture variants.
Reopen the file later by dragging it onto Excalidraw.

Pause - I'll come back to this later

Pausing closes the active editor while preserving your completed board. Your saved file remains available without running anything.

Select the save icon to store any final changes in wordle-system-design.excalidraw.
Close the Excalidraw browser tab.
Resume later by dragging wordle-system-design.excalidraw onto Excalidraw.

Delete - I don't want to use this again

Deleting the board becomes permanent once the deleted-files folder is cleared. The AWS service boxes are drawings, so this action cannot affect a cloud environment.

Press Cmd+Space to open macOS search.
Type Finder into the search bar.
Press Enter to open Finder.
Use the Finder search field to search for wordle-system-design.excalidraw.
Select wordle-system-design.excalidraw in the search results.
Use Finder's delete action to remove the selected file.
Clear Finder's deleted-files folder to make the deletion permanent.
Search for wordle-system-design.excalidraw again.

Finder should show no matching file. This confirms that the editable board has been removed from your Mac.

Nice Work!

You did it! Your interview-ready Excalidraw board now explains how a static Wordle-style game evolves into a backend for millions of daily players.

You've learned how to:

Build a problem-first architecture that grows from static delivery into server-side validation. Each added component answers a visible requirement or failure.
Calculate capacity estimates from explicit assumptions. Your board now covers average traffic, a regional midnight spike, daily writes, and dynamic concurrency.
Design resilient gameplay paths for throttling, unavailable dependencies, stale reads, and stalled analytics. Your five-minute narrative explains each trade-off in requirement order.
Secret Mission: Create an anonymous-only variant by removing identity and persistent progress. Your 60-second defense explains the lost capabilities plus the retained answer secrecy.

Ready to quiz yourself?