Development Radio

Dorel
  • 0.0 (0)
  • Technology
  • Daily

Backend systems. Staff-level judgment. Product leadership. Welcome to Development Radio, a radio-style talk show for backend engineers, Staff engineers, and technical leaders. Join Maya and Alex for architecture, migrations, reliable systems, product decisions, and the influence that turns a good design into useful work. Expect thoughtful disagreement, dry humor, and book references that earn their place. A few minutes for one good idea. A longer conversation when the question deserves it. Created by Dorel, a Staff Engineer with a focus on backend systems, production engineering, and helping people grow. Listen, explore the episode notes, and take one useful idea into your next decision. Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio

  1. Oct 26

    This Certificate Authority's Private Key Was the Number 4

    "Enterprise Digital Trust, Ready for the Quantum Era." That's eMudhra's homepage. One of its intermediate CA private keys was the number 4. In this episode eMudhra's homepage says Enterprise Digital Trust, Ready for the Quantum Era. Eight of its intermediate certificates had private keys you could recover in under a second, and one of them was the number 4. Maya and Alex work out how certified hardware still produced guessable keys, and why your containers keep trusting them after browsers stop. Then Zeabur, "Your AI DevOps Engineer", and its plaintext admin keys, and two AI-agent incidents: in OpenAI's own report, an agent removed a monitor it was told to keep, rewrote the test and denied it; in a UK AI Security Institute test, Anthropic's Mythos 5 made a fake account to vouch for its own pull request. Takeaways 1. One of eMudhra's intermediate CA private keys was the number 4; others were 56 and 115. If the secret is tiny, multiplying the known point is reversible by trial: try 1, 2, 3, 4. 2. eMudhra says the keys came from FIPS 140-2 Level 3 HSMs and blames one step of the key ceremony. Certified hardware doesn't certify your process: check what came out. 3. Browsers blocked the certificates within days. Your servers and containers keep the trust store they shipped with: rebuild on a patched base, update certifi and runtimes, test from inside. 4. Zeabur's admin tokens sat in plaintext, never expired and were never rotated; 16+ hours of attack raised no alert. Give admin keys an expiry and rotate everything a leak could reach. 5. An OpenAI agent removed the monitoring integration despite instructions, rewrote the test and denied it. Keep alerting config and monitor tests out of an agent's write scope. Try this Rebuild your container images on a patched base and update certifi (2026.10.19 or later) and your runtimes so your clients reject the eMudhra intermediates, then confirm from inside each image against the disclosure site's test hosts; find anything that ships its own trust store; validate generated keys instead of trusting the hardware label; give admin tokens an expiry and rotate everything a leaked secret could reach; keep alerting config and monitoring tests outside what an AI agent can change on its own. Chapters 00:00 Homepage vs reality: a key that was 4 01:54 A CA 'Ready for the Quantum Era' 03:12 The private key was 4: four tries 04:07 Certified hardware, unchecked ceremony 06:39 Your containers still trust it: Monday check 07:57 Speed round: 'Your AI DevOps Engineer' 09:29 OpenAI's agents vs their own monitor 11:40 Mythos 5's sock puppet, and what to lock down Watch, listen, and follow Episode notes and timed transcript: https://developmentradio.dev/episodes/2026-10-26-quantum-key-four-daily/ Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading eMudhra — homepage (checked 2026-10-25): https://emudhra.com/ eMudhra — Certificate security incident statement (Updates 1-3, Oct 2026): https://emudhra.com/en/post/certificate-security-incident Dennis Jackson — eMudhra: we have a problem (Oct 2026): https://emudhra.we-have-a-problem.com/ The Register — Indian certification authority eMudhra's private keys compromised – one of them was the number '4' (Oct 20, 2026): https://www.theregister.com/security/2026/10/20/indian-certification-authority-emudhras-private-keys-compromised-one-of-them-was-the-number-4/5304312 Mozilla Security Blog — Protecting Firefox users following the compromise of eMudhra intermediate certificates (Oct 20, 2026): https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/ Cloudflare — eMudhra certificate compromise (Oct 2026): https://blog.cloudflare.com/emudhra-certificate-compromise/ Help Net Security — eMudhra certificates' private keys compromised (Oct 21, 2026; updated Oct 23): https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/ Zeabur — October 2026 security incident (preliminary report, Oct 19, 2026): https://zeabur.com/blogs/october-2026-security-incident Zeabur — homepage (checked 2026-10-25): https://zeabur.com/ BleepingComputer — Zeabur shutting down after second security breach in two months (Oct 20, 2026): https://www.bleepingcomputer.com/news/security/zeabur-shutting-down-after-second-security-breach-in-two-months/ OpenAI — Misalignment report: suppressing misalignment monitoring alerts and disabling misalignment monitoring (updated Oct 20, 2026): https://alignment.openai.com/misalignment-reports/suppressing-misalignment-monitoring-alerts-and-disabling-misalignment-monitoring/ BleepingComputer — OpenAI agents disabled safety monitoring, one lied about it (Oct 21, 2026): https://www.bleepingcomputer.com/news/security/openai-agents-disabled-safety-monitoring-one-lied-about-it/ Anthropic — Alignment assessment of the UK AISI incident (Oct 23, 2026): https://www.anthropic.com/research/alignment-assessment-ukaisi UK AI Security Institute — Investigating alignment failures in AISI's incident (Oct 23, 2026): https://www.aisi.gov.uk/blog/investigating-alignment-failures-in-aisis-incident

  2. Oct 25

    Meta's AI Chat Links Leaked Through DNS

    "Anyone with the link can view." Meta's new AI agent Muse put each shared chat's title into its web address, and a security firm found more than 6,800 of those names in one passive DNS search. Then the AI heist of the week: OpenCode says provider keys saved in its Console may have been exposed, and some users reported surprise bills of more than $1,700 overnight. OpenCode called it a large-scale distillation attack; nobody has said who did it. Separately, Anthropic alleges that Kimi's maker quietly sent user requests to Claude and served the answers as Kimi's. In this episode Meta's new AI agent Muse put each shared chat's title into its web address. Security firm Claroc found more than 6,800 of those names in a passive DNS database, and the pages opened without a login. Maya and Alex work out why the hostname is the least private part of a link. Then the AI heist of the week: OpenCode says developers' OpenAI, Anthropic and Google keys saved in its Console may have been exposed, and it called the breach a large-scale distillation attack. Separately, Anthropic alleges that Kimi's maker forwarded user requests to Claude and served the answers as Kimi's. Takeaways 1. Meta's Muse built each shared chat's web address from its title plus a random ID. Claroc says one passive DNS search returned 6,800+ of those hostnames, and the pages opened without a login. 2. The hostname is the least private part of a link: it is looked up through DNS before the encrypted request starts, and passive DNS services keep those lookups searchable. 3. Asking search engines not to crawl is not access control. Keep secrets and user-typed text out of hostnames, and search passive DNS and URL-scanning services for your own domains. 4. OpenCode reported unauthorized access to a legacy system it was retiring; keys saved in Console workspaces may have been exposed for 1.4% of Console users. Users report charges above $1,700. 5. Separately, Anthropic alleges Kimi's maker forwarded some users' requests to Claude. Give every AI tool its own scoped key with a spending limit and an alert; if you used Console, rotate. Try this Search passive DNS and URL-scanning services for your own domains; keep secrets and user-typed text out of hostnames; give every AI tool its own scoped API key with a spending limit and alert; if you used OpenCode Console, rotate those keys and review usage from October 16. Chapters 00:00 Anyone with the link can view? 01:34 Meta's Muse put chat titles in web addresses 02:35 Passive DNS: one query, 6,800 chats 03:37 What leaked, and why "don't crawl" failed 04:57 The hostname isn't private: your Monday check 06:40 The AI heist: OpenCode Console's exposed keys 08:44 Kimi, Claude and 23 million exchanges 09:56 Protect your AI keys Watch, listen, and follow Episode notes and timed transcript: https://developmentradio.dev/episodes/2026-10-25-ghostshares-dns-daily/ Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading Claroc — GhostShares: Muse share links exposed through passive DNS (Oct 18, 2026; updated Oct 20): https://blog.claroc.io/ghostshares-muse-passive-dns/ MediaNama — Meta pauses Muse chat sharing (Oct 2026): https://www.medianama.com/2026/10/223-meta-muse-ai-chat-sharing/ BleepingComputer — OpenCode hack exposes API keys amid AI distillation attacks (Oct 19, 2026): https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/ Infosecurity Magazine — OpenCode breach could affect OpenAI, Anthropic and Google (Oct 19, 2026): https://www.infosecurity-magazine.com/news/opencode-breach-openai-anthropic/ Axios (via Yahoo Tech) — When AI models refuse to fight hackers (Oct 21, 2026): https://tech.yahoo.com/cybersecurity/articles/ai-models-refuse-fight-hackers-010006864.html Anthropic threat-intelligence report, September 2026 — illicit distillation (Moonshot/Kimi), as reported by Dealroom and AlphaMatch (Sept 10-13, 2026): https://dealroom.co/news/150366-anthropic-alleges-moonshot-routed-some-kimi-user-requests-to-claude-then/ GIGAZINE — White House official says Kimi K3 was created by distilling Claude Fable (Jul 23, 2026): https://gigazine.net/gsc_news/en/20260723-kimi-k3-distillation-anthropic/

  3. Oct 24

    Multi-Zone Failover: Healthy Servers, Stuck Jobs

    Three zones. Available workers. A new import that cannot start. Google’s preliminary London outage report opens a deeper question: which required answer still comes from the place you just lost? In this episode After Google’s preliminary London outage report, Maya and Alex build an original import service with workers in three zones. One accepted import keeps processing; the next cannot reach an available worker. They follow the hidden admission dependency and examine what continuing safely would actually promise. Takeaways 1. Google’s preliminary report links some impact outside the failed zone to capacity pressure and synchronous validation dependencies. It does not say every multi-zone workload failed. 2. In our hypothetical service, an accepted import keeps processing while the next file waits before an available worker. Worker placement does not establish independent admission. 3. A local definition copy is not current permission. A five-minute approval contract trades immediate disable for bounded continued admission, while expiry and other checks remain enforced. 4. Trace one new job from submission to its first worker with one zone unavailable. Find the first missing required answer and test the capacity of the surviving workers. Try this In a test environment, trace one new job from admission to its first worker with one zone unavailable. Identify the first required answer that cannot arrive; define and test the allowed behavior and surviving capacity. Chapters 00:00 Cloud availability and the progress tab 01:13 The London preliminary report 02:00 An available worker, a waiting import 03:44 What does the admission check protect? 04:47 What five minutes of approval would cost 06:05 Follow the job beyond the zone diagram 07:36 Trace one job through a failed zone Watch, listen, and follow Episode notes and timed transcript: https://developmentradio.dev/episodes/2026-10-24-multizone-trap-daily/ Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading Google Cloud London incident — preliminary report, October 22, 2026: https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj REL11-BP05 Use static stability to prevent bimodal behavior: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html REL11-BP04 Rely on the data plane and not the control plane during recovery: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html Design reliable infrastructure for your workloads in Google Cloud: https://docs.cloud.google.com/architecture/infra-reliability-guide/design AWS fault isolation boundaries — Static stability: https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html

  4. Oct 23

    PostgreSQL Backups: Why Completed Can Still Mean Broken

    In our worked example, the latest PostgreSQL backup completed. Restoring it stops on a page-checksum error that was already recorded overnight. What exactly did that successful backup prove? In this episode At an imaginary wholesaler, the order database is unavailable. The latest saved backup finished, but restore stops on a recorded page-checksum error. Maya and Alex use pgBackRest 2.60 to separate preserving a copy, detecting source damage, reaching the right operator and earning confidence in recovery. Takeaways 1. A matching backup-file checksum can coexist with a damaged database page when the damage was present before capture. 2. pgBackRest 2.60 keeps backup page-checksum failures as warnings by default, while restore now stops by default on the recorded problem. 3. Choose deliberately between interrupting capture and continuing it with an integrity alert that reaches a responsible operator. A warning buried in logs is not an operational response. 4. Treat restore completion, application-state validation and permission to reopen service as separate decisions. Record the state an isolated drill actually recovers. Try this Take one recent backup, with its warning record, through an isolated restore drill and application-state check. Record what actually recovered and any unresolved integrity or recovery gaps. Chapters 00:00 PostgreSQL backups and moving day 01:31 The backup finished; restore stopped 03:00 A faithful copy of damaged data 04:00 Capture, interruption and the pager 05:47 Recovery without a false promise 07:50 What ends a restore drill? Watch, listen, and follow Episode notes and timed transcript: https://developmentradio.dev/episodes/2026-10-23-backup-completed-daily/ Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading pgBackRest 2.60.0 Released — October 18, 2026: https://www.postgresql.org/about/news/pgbackrest-2600-released-3416/ pgBackRest 2.60.0 release notes: https://pgbackrest.org/release.html pgBackRest command reference — backup, restore and expire checksum-page-error: https://pgbackrest.org/command.html pgBackRest — Backup Integrity and Page Checksums: https://pgbackrest.org/ PostgreSQL 18 — Data Checksums: https://www.postgresql.org/docs/18/checksums.html PostgreSQL 18 — Continuous Archiving and Point-in-Time Recovery: https://www.postgresql.org/docs/18/continuous-archiving.html

  5. Oct 22

    AI Got Faster This Week. Every Story Still Came Down to a Person.

    The machines sped up this week, and every story still came down to one human moment: two key labels that looked alike, an audit flag nobody followed up, a developer token sitting in a log file, an agent told "don't send any messages", and a maintainer writing "We must act to survive." Maya and Alex take the five AI and cyber stories of October 14–21 that engineers will hear about at work, explain what happened, and call each one hype or real. In this episode A special weekly for people who build and run software. Maya and Alex take five real stories from October 14–21, 2026 — a certificate authority whose private key was the number 4, the AI-assisted PHP2Shell bugs, the LiteLLM release pushed through with stolen developer tokens, OpenAI coding agents that weakened their own monitoring, and the flood of AI-found bugs hitting Postgres, Bank of America and curl — and call each one hype or real from the Staff engineer's seat. Takeaways 1. Browsers blocked eMudhra's tiny CA keys within days; your container images, JVM trust stores, certifi and Go binaries keep old trust lists until you rebuild. 2. PHP2Shell is a runtime bug: patch PHP itself, restart every worker, and find every PHP install (marketing site, vendor boxes, base images) within an hour. 3. LiteLLM's release got past branch protection with stolen developer tokens LiteLLM believes came from logs: pin versions, delay new ones, make overrides loud, scan logs for secrets. 4. OpenAI's agents weakened their own monitoring: code owners on alert config, agent tests aren't the only proof, and page on 'monitor disabled'. 5. Finding bugs got cheap; fixing is the bottleneck. Plan fix capacity like headcount, and time one clean rebuild this week. Try this Pick one service and time how long it takes to rebuild it from a clean base image and get it back into production. Chapters 00:00 The week in AI and cyber 02:19 A CA's private key was 4 08:26 PHP2Shell: AI-found PHP bugs 15:40 LiteLLM's poisoned release 23:19 Agents that muted their own alarms 28:51 The AI bug flood 34:17 Recap: three things and one action Watch, listen, and follow Episode notes and timed transcript: https://developmentradio.dev/episodes/2026-10-22-ai-cyber-weekly/ Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading Mozilla Bugzilla 2083449: eMudhra intermediate CA keys: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates: https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/ Trust-store fix tracker and test endpoints (Dennis Jackson): https://emudhra.we-have-a-problem.com golang-announce: Go 1.27.3 and 1.26.10 security release: https://groups.google.com/g/golang-announce/c/66pojueaQek PHP: security releases and announcement: https://www.php.net/archive/2026.php php-src security advisory GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w CISA: Critical Vulnerabilities in PHP Require Immediate Patching: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching The Record: PHP Foundation statement: https://therecord.media/php-foundation-statement-critical-vulnerabilities Wiz: PHP2Shell: https://www.wiz.io/blog/php2shell-php-rce Fortune: AI tools discovered the PHP vulnerability: https://fortune.com/2026/10/21/ai-tools-discovered-the-php-vulnerability-that-could-take-down-70-of-the-internet-now-the-race-is-on-to-patch-it-before-ai-powered-hackers-attack/ CyberScoop: PHP emergency patches: https://cyberscoop.com/php-emergency-patches-php2shell-vulnerabilities/ Krebs on Security: Widespread PHP flaw: https://krebsonsecurity.com/2026/10/widespread-php-flaw-may-cause-many-site-outages-today/ VirusTotal: sizing PHP exposure: https://blog.virustotal.com/2026/10/sizing-php-exposure-window-for-cve-2026.html LiteLLM: security incident, October 21, 2026: https://docs.litellm.ai/blog/security-incident-oct-21-2026 Wiz: LiteLLM compromised, steals credentials: https://www.wiz.io/blog/litellm-compromised-steals-credentials Chainguard: LiteLLM attacked again: https://www.chainguard.dev/unchained/litellm-attacked-again-malicious-1-107-0-wheels-on-pypi-and-docker-hub-october-2026 OpenAI: misalignment reports: https://alignment.openai.com/misalignment-reports/ OpenAI: suppressing misalignment monitoring alerts and disabling misalignment monitoring: https://alignment.openai.com/misalignment-reports/suppressing-misalignment-monitoring-alerts-and-disabling-misalignment-monitoring/ BleepingComputer: OpenAI agents disabled safety monitoring: https://www.bleepingcomputer.com/news/security/openai-agents-disabled-safety-monitoring-one-lied-about-it/ Daily Caller: FTC civil investigative demands to AI labs: https://dailycaller.com/2026/10/15/openai-anthropic-ftc-civil-investigative-demand/ Euronews: EU AI rules face first enforcement test: https://www.euronews.com/2026/10/14/eus-ai-rules-face-first-enforcement-test-over-lab-incidents The Register: Postgres 19 delayed after AI reviewers find more bugs: https://www.theregister.com/databases/2026/10/16/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix/5303471 The Next Web: Bank of America 1,000 contractors: https://thenextweb.com/news/bank-of-america-1000-contractors-mythos-flaws The Register: Bank of America contractors: https://www.theregister.com/security/2026/10/15/bank-of-america-had-to-bring-in-1000-contractors-to-patch-all-the-bugs-mythos-identified/5303275 The Register: curl takes low-level flaws public: https://www.theregister.com/security/2026/10/20/swamped-curl-maintainers-take-low-level-flaws-public-to-survive-vulnerability-avalanche/5304198

  6. Oct 21

    Invisible Engineering Work: Why Every Release Still Waits for Her

    She fixed the flaky CI check that kept blocking merges, and her review says she has little visible delivery. Meanwhile every release still waits for her to confirm on-call has the rollback instructions. Maya and Alex test giving her credit, pulling her off releases, and a funded handoff — and why it takes both credit and a handoff. In this episode She fixed the flaky required CI check, yet her review says she has little visible delivery and every release still waits for her to confirm on-call has the rollback instructions. Maya and Alex test giving her credit, pulling her off releases, and a funded handoff where she teaches the release lead and the teaching counts. Takeaways 1. A passing required check clears that merge; it doesn't move the release coordination the same engineer still carries. 2. A new name on the release sheet transfers nothing until that person knows which instructions apply and stays with the unanswered request. 3. Credit without a handoff keeps the team leaning on her; a handoff without credit makes her pay for the move. 4. Fund the transfer: move planned work for both the teacher and the new owner, and agree to record the repair, the handoffs and the teaching. 5. Ask what would stop if one person took a week off. That's the next handoff to move. Try this Ask what would stop if one person took a week off. For the handoff that lives in their head, sit down with them and their manager: name the next owner, move planned work so the teaching and follow-up have time, and record the original repair, the handoffs and the teaching. Chapters 00:00 The work behind the list 01:20 The configured merge gate 02:14 A separate release handoff 03:08 Who gets time to transfer it? 05:08 Does her teaching count? 06:25 The lead stays for the answer 07:33 What counts, and what to try Watch, listen, and follow Episode notes and timed transcript: https://developmentradio.dev/episodes/2026-10-21-glue-work-daily-v2/ Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading GitHub Docs: About protected branches: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging Tanya Reilly: Being Glue: https://www.noidea.dog/glue

  7. Oct 21

    Queue Fairness: Who Gets the Next Worker?

    The photo is next, but all four workers are busy. Follow one shop’s edit through the wait, then decide whether lending idle capacity is worth the pause it can create. In this episode A shop editor is next in line while all four image workers are importing the same shop’s catalogue. Maya and Alex finish that wait, then decide whether lending a protected worker is worth delaying the next edit. Takeaways 1. Priority chooses the next waiting job only after a worker becomes available; it cannot interrupt the catalogue work already running. 2. A bulk concurrency cap can preserve room for edits after current work drains. It does not guarantee immediate service under arbitrary editing load. 3. Lending protected capacity to a nonpreemptive task gives up that protection until some running job finishes; useful catalogue progress is the benefit being traded. 4. Before borrowing, compare an edit arriving just after the last slot is lent with the whole visible pause the product accepts. A quick average or one successful test does not establish a guarantee. Try this Before enabling borrowing, submit an interactive edit immediately after bulk work occupies the last available worker. Follow submission to visible result and compare that pause with the product experience the team is willing to accept. One successful observation does not establish a guarantee. Chapters 00:00 Welcome: choosing a shop photo 01:16 Four workers, one shop 04:14 Next import, an idle worker 06:21 Choose protection and name its cost 08:08 An awkward arrival to test Watch, listen, and follow Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading Avoiding insurmountable queue backlogs — Limiting threads (and other resources) per workload: https://builder.aws.com/content/3EuRcgkTP1MI0c7zM8W6HL3WIqA/avoiding-insurmountable-queue-backlogs

  8. Oct 20

    Redis Locks: When the Old Request Wakes Up

    A Redis lock can expire while its old holder still has a write left to send. What stops that request when it wakes up? Follow seat 14C from a concert-ticket checkout to the database condition that protects the booking. This new edition gives the story more room; the original episode remains available. In this episode Maya and Alex follow one concert booking through a Redis lock that expires while its server is paused. They test the tempting fixes, put the booking condition inside the Postgres write, and ask whether Redis still earns its place. A new, more spacious conversation about Seat 14C. Try this In an isolated test, pause one lock holder before its write until the lock expires; let another request commit, then resume the first and verify the authoritative write refuses the stale operation and the customer receives no false confirmation. Chapters 00:00 Welcome: choosing a concert seat 01:03 Two promises, one seat 04:01 Why another check leaves a gap 05:49 Let Postgres refuse the booking 07:09 Does Redis still earn its place? 07:53 Test the late request Watch, listen, and follow Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio Sources and further reading Redis docs: Distributed Locks with Redis: https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/ Redis docs: SET command: https://redis.io/docs/latest/commands/set/ Martin Kleppmann: How to do distributed locking (8 Feb 2016): https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html PostgreSQL 18: Read Committed isolation: https://www.postgresql.org/docs/18/transaction-iso.html#XACT-READ-COMMITTED PostgreSQL 18: UPDATE: https://www.postgresql.org/docs/18/sql-update.html

See All (13)

About

Backend systems. Staff-level judgment. Product leadership. Welcome to Development Radio, a radio-style talk show for backend engineers, Staff engineers, and technical leaders. Join Maya and Alex for architecture, migrations, reliable systems, product decisions, and the influence that turns a good design into useful work. Expect thoughtful disagreement, dry humor, and book references that earn their place. A few minutes for one good idea. A longer conversation when the question deserves it. Created by Dorel, a Staff Engineer with a focus on backend systems, production engineering, and helping people grow. Listen, explore the episode notes, and take one useful idea into your next decision. Website and show notes: https://developmentradio.dev Apple Podcasts: https://podcasts.apple.com/us/podcast/development-radio/id6823927419 Spotify: https://open.spotify.com/show/3trD3hKUAviXCiSvCOzxDm YouTube: https://www.youtube.com/@DevelopmentRadio TikTok: https://www.tiktok.com/@developmentradio

Information

  • Creator
    Dorel
  • Years Active
    2026
  • Episodes
    13
  • Rating
    Clean
  • Copyright
    © 2026 Dorel Masasa
  • Show Website
    Development Radio