Your concept feed For you Start small Foundations Recursion Arrays Linked lists Trees Heaps Ranges Graphs Backtracking Tries Strings Think in DP 1D DP 2D DP 3D DP Advanced DP Greedy Math & bits Connect LLD HLD Learn Saved 0 Review 0 43 ideas
Follow the connections in this topic
A small step before this topic
Let’s picture it Let’s start with three stops. Home. Then the park. Then the café. Just a few things in a row.
One little change Point to the middle one. The park is second. In Python, its position is 1, because counting starts at 0.
Now it has a name That’s a list. A list keeps things in order. An index is just a position in that list.
No pressure. Just try it. Which place is at position 0? Home Park
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Now visit each stop. You don’t need three different instructions. “Visit the next place” works each time.
One little change One, then the next. Finish home. Move to the park. Then do the same at the café.
Now it has a name That repeat is a loop. One small action, repeated for each item. Three stops mean three visits.
No pressure. Just try it. Add one more stop. How many visits now? 3 4
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it What if it rains? Let’s choose the café on rainy days, and the park on sunny days.
One little change Today is sunny. The rule stays the same. The weather changed, so we choose the other place.
Now it has a name That’s an if / else. Raining?
Yes: café
No: park
A condition is a yes-or-no question. Its answer chooses which step happens next.
No pressure. Just try it. It’s raining. Where does our rule send us? The park The café
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Name a tiny job. Our job is “add one.” Give it 3, and it gives back 4.
One little change Try a new input. Give the same job 8. It gives back 9. We can reuse the instructions.
Now it has a name That job is a function. Input goes in. An answer comes back. In Python, return sends the answer back.
No pressure. Just try it. What does add-one return for 5? 6 5
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Picture a pile of plates. Blue goes down first. Pink goes on top.
One little change Take the top one. Pink comes off first, even though blue arrived first.
Now it has a name That’s a stack. Last in, first out. Paused function calls work this way too: finish the newest call, then return.
No pressure. Just try it. Add green on top. Which plate comes off next? Blue Green
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Have we visited the park? Keep a little checklist of places we’ve seen.
One little change Write park again. We still only need one check beside park. We’re remembering whether, not how many times.
Now it has a name That’s a set. A set keeps distinct items. “Is park in here?” becomes a quick membership check.
No pressure. Just try it. Add park twice. How many copies in a set? 1 2
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Let’s remember a little more. The park is five minutes away. Write that beside its name.
One little change Look it up later. Ask for “park.” The notebook gives you 5. No need to measure the walk again.
Now it has a name That’s a dictionary. A key finds a value. Here, the place name is the key and the time is the value.
No pressure. Just try it. We now write park: 6. What does park return? 5 and 6 6
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Draw our little walk. A dot for each place. A line where we can walk directly.
One little change Two short walks can join. Home to park, then park to café. We can reach the café without a direct road.
Now it has a name Dots and links have names. A dot is a node. A link is an edge. Together, they make a graph.
No pressure. Just try it. Must two places share a direct road to be reachable? No Yes
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Same door. One small difference. You have a key. Your friend doesn’t. The door is the same, but your next move isn’t.
One little change Remember the key. If we only write down “at the door,” we lose something important.
Now it has a name That little note is a state. A state remembers what we need to continue. Here: where we are, and whether we have the key.
No pressure. Just try it. Is “at the door” enough to decide if we can enter? Yes Not by itself
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it How many little jobs? Visit three places. Say hello once at each. That’s three hellos.
One little change Now try every pair. Three people each greet all three people, including themselves for this toy count. That’s nine greetings.
Now it has a name Count how the work grows. One pass grows with n. Trying every pair grows with n × n. Code length doesn’t tell us that.
No pressure. Just try it. With 4 items, how many ordered pairs, including self-pairs? 4 16
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Find 8 in a sorted row. Start with 2, 4, 6, 8, 10. Look at the middle: 6.
One little change Keep the side that can work. 8 is bigger than 6. Everything on the left is too small, so we can leave it behind.
Now it has a name Keep one promise. If 8 is present, it stays in the part we keep. That repeating promise is called an invariant.
No pressure. Just try it. Would this left-or-right shortcut work on an unsorted row? Not reliably Yes
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Open a box. There’s a smaller box inside. We already know how to open a box.
One little change Do the same small job again. Open the smaller box. Keep going until there isn’t another box inside.
Now it has a name That’s the idea of recursion. A function asks itself to handle a smaller case. The empty box is our stopping point: the base case.
No pressure. Just try it. What if every box contains another box forever? We stop anyway We need a stopping case
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Count a tiny family of dots. One parent has two children. Each child says, “There’s one of me.”
One little change Let the answers travel up. The parent adds the two answers, then counts itself: 1 + 1 + 1.
Now it has a name That works for bigger trees too. my answer
left answer
right answer
Ask each child about its little tree. Combine the answers. You don’t need to hold the whole tree in your head.
No pressure. Just try it. Do we also count the parent itself? Yes No
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Two trees can make different promises. In a search tree, smaller keys go left and larger keys go right. We’ll use distinct keys here.
One little change A heap promises something else. A min-heap keeps the smallest value at the top. Its left and right sides need not be sorted.
Now it has a name Choose the promise you need. Looking for an ordered key? Think search tree. Repeatedly taking the smallest? Think min-heap.
No pressure. Just try it. Does a min-heap promise its left side is smaller than its right? Yes No
Next little step 1 / 4 A reminder Python My thought A small step before this topic
Let’s picture it Car and cat start the same way. Write c, then a, just once. Split where the words become different.
One little change A prefix isn’t always a word. If we only stored cart, reaching c-a-r is not enough to say car was stored too.
Now it has a name Mark where each word ends. This shared-prefix tree is a trie. The word-end mark tells a whole word apart from just its beginning.
No pressure. Just try it. Only cart is stored. Does car count as a stored word? Yes No
Next little step 1 / 4 A reminder Python My thought A small step before this topic
A familiar idea Start with what people need to do. A note app must save a note and read it later. Before choosing databases, ask how many people use it and what failures are acceptable.
One new wrinkle Turn “fast” into a measurable promise. which request?
how often?
how fast?
A latency objective needs an operation, percentile, time limit, and measurement window. Reads and writes may need different promises.
Try a tiny example Separate steady traffic from bursts. Ten thousand requests per day is an average, not a peak. A short burst can dominate the capacity we actually need.
Notice what matters Choose boxes only after these questions. requirements
tradeoffs
architecture
List operations, scale assumptions, consistency needs, availability goals, and what is outside scope. Revisit them when a design choice conflicts.
No pressure. Just try it. Does average traffic alone tell us how many workers a peak needs? No Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
Let’s picture it A request crosses several boundaries. A name resolves to an address. A connection reaches a server. TLS protects the connection. HTTP carries the request and response.
One little change Some setup can be reused. reused connection
application
storage
Cached DNS and existing connections can avoid repeated setup. The application still performs its own validation, computation, and storage work.
Now it has a name Every boundary can consume time or fail. request sent
work done?
response missing
A deadline must cover the whole operation. A timeout does not prove the server did nothing; its response might simply be lost.
No pressure. Just try it. Does a timeout prove a write never committed? No Yes
Next little step 1 / 4 Mental model Why it fits A reminder Python My thought A small step before this topic
Let’s picture it Make one operation’s promise explicit. request
validated operation
response
Define its resource, input, validation, response, and errors. For writes, also define what a repeated request means.
One little change Pages need a stable ordering key. Two notes can have the same timestamp. Add a unique ID as a tie-breaker, then continue after both cursor values.
Now it has a name A cursor is not permission. page position
authorization separately
A cursor locates the next page. The server must still enforce the caller’s access rights and decide snapshot behavior under concurrent changes.
No pressure. Just try it. Is a timestamp alone always enough for gap-free keyset pagination? No, ties need a stable unique key Yes
Next little step 1 / 4 Mental model Why it fits A reminder Python My thought A small step before this topic
Let’s picture it A module does not have to be a separate server. one deployment
separate responsibilities
Keep notes, accounts, and notifications behind clear code boundaries first. They can begin inside one deployable application.
One little change Split deployment when independence earns its cost. independent changes
network costs
Separate services can scale and ship independently, but calls now face network latency, partial failure, and independent data ownership.
Now it has a name Choose one owner for each fact. state owner
published contract
If several services write the same business state without a contract, deployment separation may increase coupling instead of reducing it.
No pressure. Just try it. Does putting every class in its own service automatically reduce coupling? No Yes
Next little step 1 / 4 Mental model Why it fits A reminder Python My thought A small step before this topic
Let’s picture it One worker becomes several. A load balancer chooses a healthy worker for each request. More workers can share traffic, but they need the state required to serve any user.
One little change Do not hide essential session state in one worker. request 1 → A
request 2 → B
If only A remembers a user’s session, routing the next request to B breaks the workflow. Use an explicit shared or client-carried session design.
Now it has a name Health and capacity are changing facts. ready workers
drain safely
observe load
Round-robin is simple, but readiness checks, connection draining, slow workers, and uneven request costs affect real routing.
No pressure. Just try it. Does adding app workers automatically fix a saturated database? No Yes
Next little step 1 / 4 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea Start with the questions storage must answer. read pattern
write pattern
invariant
Which record do we fetch? Which records do we list together? Which changes must succeed together? Those choices shape keys, indexes, and transactions.
One new wrinkle An index is another maintained structure. faster reads
extra write work
It makes certain lookups cheaper, but every relevant write must maintain it. Indexes cost memory, disk, and write work.
Try a tiny example Put an invariant inside the write boundary. check + decrement
one database operation
Claim stock only if enough remains, in one conditional update. Reading first and writing later can race with another claimant.
Notice what matters Choose a data model, not a slogan. queries
constraints
chosen model
Relational, document, key-value, and wide-column models favor different access patterns. “NoSQL” does not mean every product has the same guarantees.
No pressure. Just try it. Does a separate SELECT followed by an unconditional UPDATE protect stock from concurrent claims? Not by itself Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea A saved value can have several copies. A leader accepts a write and replicas receive it. If copying is asynchronous, a replica may temporarily show the old value.
One new wrinkle An acknowledgment needs a definition. accepted where?
durable where?
Did the write reach memory, durable storage, or a required set of replicas? Those are different durability and latency promises.
Try a tiny example Overlapping sets are useful, but not a protocol. set overlap
plus protocol rules
A read quorum and write quorum may intersect. That alone does not define ordering, leadership, version selection, or safe behavior during failures.
Notice what matters Agreement needs explicit coordination. leader + log
quorum agreement
Consensus protocols such as Raft coordinate a replicated log under stated failure assumptions. Replication is not simply copying a dictionary.
No pressure. Just try it. Does reading from any asynchronous replica always provide read-your-writes? No Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea Copies and partitions solve different problems. replicas: same keys
shards: different keys
Replication copies the same data. Partitioning gives different keys to different owners so storage and work can be spread out.
One new wrinkle Choose a key that spreads the real workload. many quiet keys
one hot key
Hashing user IDs can spread users, but one extremely busy user may still overload its shard. Equal key counts are not equal traffic.
Try a tiny example A hash ring limits movement during membership changes. Consistent hashing assigns a key to the next token on a ring. Virtual nodes spread each server across several ranges.
Notice what matters Movement still needs a data migration plan. New routing does not instantly move stored bytes. Define copying, cutover, versioning, and behavior while old and new owners coexist.
No pressure. Just try it. Does consistent hashing automatically solve a single hot key? No Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea A nearby copy can save repeated work. On a cache hit, return the saved value. On a miss, read the source of truth and fill the cache. That is cache-aside.
One new wrinkle The copy can outlive the truth. If the database changes but the cache does not, a fast answer can be stale. Choose expiry, invalidation, or versioned keys deliberately.
Try a tiny example A miss can become a crowd. many misses
one overloaded source
If many requests miss together, all may hit the database. Single-flight work, jittered expiry, or controlled stale serving can reduce that stampede.
Notice what matters Cache only where the contract permits. freshness
ownership
cache key
Private responses need correct identity-aware keys and access controls. A TTL is a freshness choice, not a substitute for authorization.
No pressure. Just try it. Does a long TTL guarantee that cached data is correct until it expires? No, the source can change earlier Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea A queue lets work wait. The API accepts a job and a worker processes it later. Arrival rate and processing rate no longer need to match at every instant.
One new wrinkle Acknowledgment creates a failure window. A worker may finish its effect, then lose the acknowledgment. The queue can deliver that job again.
Try a tiny example Use stable job identities. job ID
effect + dedup record
A duplicate-safe consumer recognizes the same logical job. In a real system, recording completion and applying its effect need a shared durable boundary.
Notice what matters Queues do not make overload disappear. arrival > service
backlog grows
Backlog grows when arrivals exceed service capacity. Bound retries, monitor age, apply backpressure, and route persistent failures for inspection.
No pressure. Just try it. Does acknowledging only after work automatically prevent duplicate effects? No, the acknowledgment can be lost Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
Let’s picture it Large bytes and searchable facts have different jobs. database: metadata
object store: bytes
Store a video as an object. Keep its owner, status, size, and object key in a database that can answer application queries.
One little change Use stable object identities. A versioned or content-addressed key avoids confusing an old cached object with a replacement. Metadata points to the intended version.
Now it has a name A CDN can serve a nearby copy. Cache suitable bytes near readers. Private assets still need access checks or bounded signed access; public caching rules must not leak private content.
No pressure. Just try it. Does possession of an object hash automatically grant permission to read it? No Yes
Next little step 1 / 4 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea One slow dependency can occupy every worker. slow dependency
waiting workers
queue grows
Requests keep waiting, new requests pile up, and the caller becomes unhealthy too. Give downstream work a bounded deadline.
One new wrinkle Retries can multiply the pressure. failure
many retries
more load
Retry only suitable failures, with a bounded budget and jittered backoff. A timed-out write needs idempotency before blindly trying again.
Try a tiny example A circuit can stop repeated calls temporarily. After enough failures, reject quickly for a cooldown. Then permit a controlled probe before trusting the dependency again.
Notice what matters Isolate resources and plan recovery. Separate pools or limits prevent one dependency from consuming everything. Test failover, backups, restoration, and degraded behavior against explicit recovery goals.
No pressure. Just try it. Should every layer independently retry an operation three times without a shared budget? No, retries can multiply Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea “The latest value” needs a precise promise. write: version 7
read: version 6
One user writes a note, then reads an older replica. Eventual convergence and read-your-writes are different guarantees.
One new wrinkle A partition separates communication, not intent. side A
network split
side B
If two sides cannot communicate, an operation may have to wait or fail to preserve a single up-to-date view. Accepting everywhere can require weaker consistency.
Try a tiny example CAP is about behavior during that split. during partition
operation-specific choice
It does not mean “pick any two” for every normal request. State which operations favor availability and which must preserve stronger consistency.
Notice what matters A version can expose what the reader needs. required version
replica version
serve only if ready
A read-your-writes token can require at least the version the client already observed. A lagging replica must wait, reroute, or reject.
No pressure. Just try it. Does eventual consistency alone guarantee that your next read sees your own last write? No Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea A database write and an event must agree. save order
crash gap
publish event
Saving an order then publishing its event leaves a gap: a crash between the two can save the order without notifying anyone.
One new wrinkle Put the event beside the change. state change
outbox row
one commit
Write business state and an outbox row in one database transaction. Either both commit or neither does.
Try a tiny example Publish the outbox after commit. relay sends
ack uncertain
may resend
A relay reads pending rows and sends them. It can crash after sending but before marking sent, so duplicates remain possible.
Notice what matters Pair atomic intent with duplicate-safe consumers. durable intent
idempotent handling
The outbox prevents lost publication intent. It does not make arbitrary downstream effects exactly once.
No pressure. Just try it. Does an outbox remove every possibility of duplicate event delivery? No Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
Let’s picture it A workflow crosses several owners. Reserve inventory, authorize payment, then arrange shipping. Each service can commit locally, but there is no single simple rollback across them.
One little change A later failure needs a business response. failure
compensate earlier steps
If shipping fails, release inventory and void or refund payment according to their contracts. Those are new actions, not erased history.
Now it has a name Compensations can fail too. durable workflow
retry
reconcile
Store workflow state, retry safely, and make unresolved cases visible. A saga does not make intermediate states invisible to everyone.
No pressure. Just try it. Is compensation identical to rolling back an uncommitted database transaction? No, it is a new business action Yes
Next little step 1 / 4 Mental model Why it fits A reminder Python My thought A small step before this topic
Let’s picture it Give a caller a refillable budget. capacity: 3
request: −1
refill over time
A bucket holds at most three tokens. Each request spends one. Tokens refill over time, allowing short bursts but limiting sustained traffic.
One little change Refill only up to capacity. old tokens + refill
cap at capacity
Unused time should not build unlimited burst credit. Add elapsed-time tokens, then cap the result.
Now it has a name Shared enforcement needs shared state. server A bucket
server B bucket
global limit?
A separate full bucket on every server multiplies the effective allowance. Decide whether the limit is local, per-user global, or approximate.
No pressure. Just try it. Do three independent capacity-ten buckets enforce one global burst limit of ten? No, they may admit thirty Yes
Next little step 1 / 4 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea Measure the promise the user experiences. traffic
errors
latency
saturation
A successful API call is not enough if it arrives too late. Track request rate, errors, latency distributions, and resource saturation.
One new wrinkle Averages hide the slow tail. Nine requests take 10 milliseconds; one takes 1000. The average does not describe the experience of that slow request.
Try a tiny example Use different signals for different questions. Metrics show trends. Logs record selected events. Traces connect spans across a request. Correlate them without leaking secrets or exploding label cardinality.
Notice what matters An error budget makes the target actionable. 10,000 requests
10 failures allowed
For a 99.9% success objective over 10,000 eligible requests, ten failures consume the whole request-based budget.
No pressure. Just try it. Can an average latency show how bad the slowest one percent feels? Not reliably Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea Knowing who called is only the first check. who are you?
may you read this note?
Authentication identifies a principal. Authorization asks whether that principal may perform this operation on this particular object.
One new wrinkle Do not trust ownership supplied by the client. trusted identity
stored policy
decision
Load the stored object and compare its actual owner or policy with the trusted principal. A request saying owner=me proves nothing.
Try a tiny example Protect the rest of the boundary too. transport
permissions
data handling
Use TLS, managed secrets, bounded inputs, safe queries, abuse controls, and minimal data exposure. Avoid inventing custom cryptography or logging credentials.
Notice what matters Treat private links as capabilities. scoped access
limited lifetime
Signed access should be narrowly scoped and expire. Leaking a valid bearer link can let another person use it during its lifetime.
No pressure. Just try it. Does a valid login automatically authorize reading any record ID? No Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea A rate and a duration reveal work in flight. 100 / second
× 0.2 seconds
20 in flight
At 100 requests per second and 0.2 seconds average service time, about 20 requests are active in a stable system.
One new wrinkle Leave room for bursts and failures. steady work
headroom
failure reserve
Sizing every worker at full utilization leaves no room for uneven load or one failed worker. Headroom is an explicit assumption, not free capacity.
Try a tiny example Storage is more than record count. bytes × retention
replicas + indexes
hot key
Estimate bytes per write, retention, replication, indexes, and overhead. Also estimate read bandwidth and the hottest key, not only total requests.
Notice what matters Check estimates with measurements. Little’s Law describes stable averages. It does not promise tail latency during overload or predict how every implementation scales.
No pressure. Just try it. Does average concurrency alone guarantee a p99 latency target? No Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought A small step before this topic
A familiar idea A short code is a lookup key. short code
destination URL
Creating a link stores code → destination. Opening it reads that mapping and returns a redirect. Reads may greatly outnumber creates.
One new wrinkle Give creation one durable uniqueness boundary. allocate ID
encode
unique stored mapping
A unique allocator or collision-checked random code creates the key. Encoding a counter in base 62 makes it shorter, not secret.
Try a tiny example Put a cache on the repeated read path. Redirects can look up popular codes nearby. Updates, expiry, or abuse blocking need an invalidation and freshness policy.
Notice what matters Keep the hard questions visible. uniqueness
expiry
abuse
analytics
Define custom aliases, expiration, redirect mutability, analytics, and malicious-link handling. Each changes the write and read contracts.
No pressure. Just try it. Does base-62 encoding turn a sequential ID into an unguessable secret? No Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea Choose when to assemble the timeline. push on write
pull on read
When someone posts, push its ID into followers’ inboxes—or wait until a follower reads and merge followed authors’ posts.
One new wrinkle A celebrity makes the difference visible. 10 followers
millions of followers
Pushing one post to ten followers is small. Pushing to millions creates a large fan-out burst. Pulling shifts that work toward readers.
Try a tiny example A hybrid can give different authors different paths. stored inbox
pulled authors
merged feed
Push ordinary authors’ posts. Pull high-fan-out authors at read time, then merge candidates into one ordered page.
Notice what matters Ordering is not the whole product. Ranking, privacy, deletions, blocked users, duplicates, and fresh pagination all need contracts. A cached post ID must not bypass current access rules.
No pressure. Just try it. Is fan-out-on-write always the best choice regardless of follower count? No Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea A live connection is not message durability. live delivery
durable history
A WebSocket can carry a message quickly, but the message must be stored and identified if clients should recover it after disconnecting.
One new wrinkle Order messages within a conversation. conversation
sequence 1, 2, 3
Assign a server-side sequence through one coordinated conversation write boundary. Wall-clock timestamps alone can tie or disagree across clients.
Try a tiny example A retry should reuse the same message identity. client ID
retry
same committed message
The client sends a stable request ID. A repeated send returns the earlier committed sequence rather than appending a second message.
Notice what matters Reconnect from a known position. last sequence
fetch gap
resume live
The client asks for messages after its last received sequence. Delivery acknowledgments and read receipts are separate from durable acceptance.
No pressure. Just try it. Does successfully writing to a WebSocket prove the recipient stored or read the message? No Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea Let large bytes bypass the application worker. client
object storage
metadata service
The app creates an authorized upload session. The client sends parts directly to object storage using narrowly scoped access.
One new wrinkle A part can be retried independently. part 1 ✓
part 2 retry
part 3 ✓
Part numbers and checksums identify progress. Retrying one failed part should not require resending the whole file.
Try a tiny example Completion is a checked transition. Verify all required parts and integrity before marking metadata ready. Uploading bytes and publishing a usable file are different states.
Notice what matters Clean up both kinds of leftovers. expired session
orphaned bytes
access checks
Expired sessions, incomplete parts, and objects without committed metadata need bounded cleanup. Private downloads still require authorization.
No pressure. Just try it. Should a file appear ready merely because an upload session was created? No Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea One event may need several delivery channels. A saved reminder might become email, push, or both. Preferences and channel capabilities decide which jobs should exist.
One new wrinkle Give each intended delivery its own identity. Use event, recipient, and channel together. Retrying email should not accidentally suppress an independent push notification.
Try a tiny example Providers have limits and uncertain outcomes. queue
provider
acceptance uncertain
Queue work by channel, pace calls, retry suitable failures, and record provider responses. A timeout may occur after the provider accepted the message.
Notice what matters Recheck preferences at the right boundary. queued earlier
preference changed
check before send
A user may unsubscribe while a job waits. Define which notifications remain permitted and check before attempting delivery.
No pressure. Just try it. Does one dedup key per event distinguish email from push for two different users? No, include recipient and channel Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea Search needs a different view of the same documents. token
matching document IDs
A primary store keeps documents. An inverted index maps each token to documents containing it, making token lookup efficient.
One new wrinkle The index is derived data. source update
index event
new postings
Document changes must update postings and remove old terms. A delayed indexing worker can make search temporarily stale.
Try a tiny example Autocomplete and full search share pieces, not objectives. prefix suggestions
document ranking
A trie or prefix index suggests beginnings. Full search also needs tokenization, matching, ranking, and result permissions.
Notice what matters Authorization still applies to results. index candidates
permission check
results
A stale index must not reveal a document the user may no longer read. Filter with a trusted visibility policy at serving time.
No pressure. Just try it. Does updating the source document automatically remove its old search terms? No, maintain or rebuild the derived index Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea A crawler has a frontier, not just a loop. discovered URLs
frontier
fetch when allowed
Discovered URLs wait for permission and scheduling. A seen set prevents repeatedly adding the same canonical URL.
One new wrinkle Be polite per host, not only globally. host A: wait
host B: ready
Two URLs on one host may need spacing, while another host can be served independently. Keep a next-allowed time per host.
Try a tiny example Permission and safety are separate checks. policy
network safety
resource bounds
Honor applicable robots rules and access policies. Also prevent fetches into private networks, unsafe redirects, or unexpectedly large responses.
Notice what matters Bound discovery and retries. Pages can link forever or generate endless URL variations. Set crawl scope, depth, byte budgets, timeouts, and retry limits.
No pressure. Just try it. Does one global requests-per-second limit guarantee polite spacing for each host? No Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea Count events by when they happened. An event created at second 12 may arrive after one created at second 18. Arrival order and event time are different.
One new wrinkle Deduplicate before increasing a count. same event ID
one contribution
A queue may repeat an event. A stable event ID prevents one logical action from incrementing the same aggregate twice.
Try a tiny example Choose how long late data may revise results. on-time
allowed late
too late
A watermark is an explicit progress assumption. Events older than the accepted lateness boundary may be dropped or handled through a correction path.
Notice what matters A displayed count may still be provisional. provisional window
finalized or corrected
Partitioning, delayed events, and recovery affect freshness. Define when a window is final and how corrections reach readers.
No pressure. Just try it. Does processing arrival order automatically preserve the time when events actually occurred? No Yes
Next little step 1 / 5 Mental model Why it fits Design walkthrough A reminder Python My thought A small step before this topic
A familiar idea Explain one ordinary write first. accept
validate
commit
confirm
Who accepts it, who validates it, where does it commit, and what confirms success? A missing answer often reveals an unclear ownership boundary.
One new wrinkle Then follow one read. source or cache?
fresh enough?
authorized?
Which copy answers, how stale may it be, and who checks permission? Faster reads are useful only if their contract remains correct.
Try a tiny example Now lose one response. effect maybe done
retry
safe outcome?
Ask what a retry does after the first attempt may already have succeeded. This exposes missing identity and transaction rules.
Notice what matters Name the tradeoff you chose. requirements
chosen boundary
known limitation
A good design is not the one with the most boxes. It explains why its assumptions, costs, and failure behavior fit this workload.
No pressure. Just try it. Does drawing more services by itself make a design stronger? No, explain the guarantees and tradeoffs Yes
Next little step 1 / 5 Mental model Why it fits A reminder Python My thought Keep a connection for later. Tap the bookmark on any post to find it here.
Explore the course