--- title: Two Places at Once | daily.dev description: Step 5 of a series building a production social-wishlist app covers implementing a Settings screen with profile editing and account deletion. Key challenges... canonical: https://daily.dev/posts/two-places-at-once-sxswrnn5f twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Two Places at Once | daily.dev og:description: Step 5 of a series building a production social-wishlist app covers implementing a Settings screen with profile editing and account deletion. Key challenges... og:url: https://daily.dev/posts/two-places-at-once-sxswrnn5f og:image: https://api.daily.dev/og/posts/SXSWrNN5F.png og:image:alt: Two Places at Once og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Two Places at Once **[Medium](https://daily.dev/sources/medium_js)** · 9 min read · 0 upvotes · 0 comments ## Summary Step 5 of a series building a production social-wishlist app covers implementing a Settings screen with profile editing and account deletion. Key challenges addressed include keeping user data consistent across Clerk (auth) and a FastAPI backend, fixing date picker wheel mismatches caused by zero-padding, ensuring Pydantic models declare all fields the client sends, and safely deleting accounts by revoking Clerk credentials first before flagging the database record. The post also covers guarding writes at the database level using DynamoDB conditional expressions to prevent stale cache from allowing writes on deleted accounts. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### In what order should you delete a user's Clerk account and flag their backend record to avoid stranding a live login? Delete the Clerk user first, then flag the backend record as deleted. Because either call can fail, the step that runs second must be the one that fails harmlessly; flagging the record first risks a failed Clerk delete leaving live credentials behind a record that already says the account is gone, fixable only from a dashboard, whereas deleting Clerk first means a failure changes nothing and the user simply retries. _daily.dev surfaces posts like this for developers hardening account deletion flows against partial failures._ ### How do you stop a deleted user from still writing data through a stale in-process cache in a distributed backend? Guard writes at the database table itself rather than trusting the in-memory cache. Deletion only sets an is_deleted flag and evicts the user from the cache on the instance that handled it, but other instances may still have the user cached, so every mutating endpoint attaches a condition the database re-checks on each write, requiring the record to exist and not be flagged deleted, since reads naturally re-fetch but writes cannot. _Developers debugging multi-instance cache consistency issues can track patterns like this via daily.dev._ ### Why does a saved birthday load back as blank picker wheels in a date-of-birth UI? A padded stored value like "01" does not match the raw value a picker wheel was built from, such as "1", so the wheel selects nothing even though the record holds a valid date. The fix strips zero-padding when loading the value so it matches the raw wheel item, then pads it back before saving, keeping the raw-value versus padded-label rule in one shared component. _daily.dev helps developers hunting down subtle form and picker state bugs like padded value mismatches._ ## Similar posts on daily.dev - [Signed, Sealed, Delivered](https://daily.dev/posts/signed-sealed-delivered-1n0myntek) · Medium · 0 upvotes · 0 comments - [How to Build a Fashion App That Helps You Organize Your Wardrobe](https://daily.dev/posts/how-to-build-a-fashion-app-that-helps-you-organize-your-wardrobe-fmnc0hv6y) · freeCodeCamp · 137 upvotes · 2 comments --- Tags: [#fastapi](https://daily.dev/tags/fastapi), [#aws-dynamodb](https://daily.dev/tags/aws-dynamodb) [View this post on daily.dev](https://daily.dev/posts/two-places-at-once-sxswrnn5f) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Two Places at Once","url":"https://daily.dev/posts/two-places-at-once-sxswrnn5f","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/two-places-at-once-sxswrnn5f"},"datePublished":"2026-07-27T19:32:42.842Z","dateModified":"2026-09-14T07:14:44.612Z","description":"Step 5 of a series building a production social-wishlist app covers implementing a Settings screen with profile editing and account deletion. Key challenges...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/cdc43ee184883ce7c018f4777170c989?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/cdc43ee184883ce7c018f4777170c989?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/two-places-at-once-sxswrnn5f","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"fastapi,aws-dynamodb","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Two Places at Once"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/two-places-at-once-sxswrnn5f#faq","mainEntity":[{"@type":"Question","name":"In what order should you delete a user's Clerk account and flag their backend record to avoid stranding a live login?","acceptedAnswer":{"@type":"Answer","text":"Delete the Clerk user first, then flag the backend record as deleted. Because either call can fail, the step that runs second must be the one that fails harmlessly; flagging the record first risks a failed Clerk delete leaving live credentials behind a record that already says the account is gone, fixable only from a dashboard, whereas deleting Clerk first means a failure changes nothing and the user simply retries. daily.dev surfaces posts like this for developers hardening account deletion flows against partial failures."}},{"@type":"Question","name":"How do you stop a deleted user from still writing data through a stale in-process cache in a distributed backend?","acceptedAnswer":{"@type":"Answer","text":"Guard writes at the database table itself rather than trusting the in-memory cache. Deletion only sets an is_deleted flag and evicts the user from the cache on the instance that handled it, but other instances may still have the user cached, so every mutating endpoint attaches a condition the database re-checks on each write, requiring the record to exist and not be flagged deleted, since reads naturally re-fetch but writes cannot. Developers debugging multi-instance cache consistency issues can track patterns like this via daily.dev."}},{"@type":"Question","name":"Why does a saved birthday load back as blank picker wheels in a date-of-birth UI?","acceptedAnswer":{"@type":"Answer","text":"A padded stored value like \"01\" does not match the raw value a picker wheel was built from, such as \"1\", so the wheel selects nothing even though the record holds a valid date. The fix strips zero-padding when loading the value so it matches the raw wheel item, then pads it back before saving, keeping the raw-value versus padded-label rule in one shared component. daily.dev helps developers hunting down subtle form and picker state bugs like padded value mismatches."}}]} ```