# worker Published articles for worker. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Worker Backpressure (Part 1) DevFeed: [Worker Backpressure (Part 1)]() Original publisher: [Read original article]() Author: Mikalai Barysau Published: 2026-09-17T00:00:00Z Content type: article Language: en Sources: [Canva Engineering]() Topics: [backpressure](), [Back end](), [reliability]() Tags: [backend](), [backpressure](), [dependencies](), [outage](), [queue](), [reliability](), [worker]() ### AI overview Canva describes Worker Backpressure, a reliability mechanism for queue workers that slows processing when dependencies fail and speeds it back up after recovery. During a cloud-provider outage, the mechanism helped prevent failed messages from accumulating on the Dead Letter Queue and avoided an on-call page. ### Source excerpt How we taught Canva's queue workers to slow down when dependencies fail, then speed back up on their own. ## Bridging Pub/Sub to Temporal with Standalone Activities DevFeed: [Bridging Pub/Sub to Temporal with Standalone Activities]() Original publisher: [Read original article]() Author: Houman Kargaran Published: 2026-07-28T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [execution](), [client](), [Latency](), [Cloud]() Tags: [bridging](), [client](), [cloud](), [community](), [execution](), [latency](), [worker](), [workflow]() ### AI overview This guest post explains how Temporal Standalone Activities can connect Pub/Sub message handling to durable execution without wrapping each activity in a Workflow. It describes how this approach can reduce application-side retry, state-tracking, reconciliation, and monitoring complexity, while offering lower latency for short-lived activity executions. ### Source excerpt How a Temporal Standalone Activity bridges Pub/Sub to Durable Execution, keeping your event handler thin. ## Why teams run Temporal workers with Encore DevFeed: [Why teams run Temporal workers with Encore]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-07-09T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Back end](), [distributed-systems](), [Provisioning](), [Code]() Tags: [backend](), [community](), [distributed](), [incident](), [provisioning](), [queue](), [retries](), [worker](), [workflows]() ### AI overview The article explains how teams combine Temporal workers with Encore services to build backends with durable, long-running workflows and infrastructure provisioned across environments. Temporal preserves workflow state, resumes after worker crashes, avoids repeating completed side effects, and supports waiting for external signals; Encore handles infrastructure provisioning and orchestration. ### Source excerpt How teams run Temporal workers as an Encore service to get durable workflows, typed APIs, and infrastructure provisioned from the same code. ## Route specialized workloads DevFeed: [Route specialized workloads]() Original publisher: [Read original article]() Author: Cecil Phillip Published: 2026-05-11T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [GPU](), [Machine learning](), [cpu](), [data analytics](), [Hardware]() Tags: [analytics](), [cost](), [cpu](), [gpu](), [ml](), [queues](), [scaling](), [separate](), [temporal-concepts](), [worker]() ### AI overview The article describes a Temporal Validated Pattern for routing Activities with different resource requirements to separate Task Queues. Dedicated Worker pools can handle GPU-intensive machine learning, CPU, high-memory analytics, and specialized hardware workloads independently. ### Source excerpt Route ML, analytics, and CPU Activities to separate Temporal Task Queues. Cut GPU costs by 60-80% while scaling each Worker pool independently. ## Ensure Activity execution on the same Worker DevFeed: [Ensure Activity execution on the same Worker]() Original publisher: [Read original article]() Author: Cecil Phillip Published: 2026-05-11T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [execution](), [Workers](), [file](), [data]() Tags: [caching](), [connection-pooling](), [data](), [execution](), [files](), [queues](), [temporal-concepts](), [worker]() ### AI overview This article explains how Temporal Worker-specific Task Queues can keep all Activities in a workflow on the same Worker, preserving data locality for file processing, ML model caching, and database connection pooling. ### Source excerpt Stop re-downloading multi-GB files between Activities. Use Worker-specific Task Queues in Temporal to keep all Activities on the same Worker. ## Per-worker, and global, IO bandwidth in explain plans DevFeed: [Per-worker, and global, IO bandwidth in explain plans]() Original publisher: [Read original article]() Author: depesz Published: 2026-02-21T13:24:57Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [IO](), [parallel]() Tags: [analyze](), [execution](), [explain](), [explain-depesz-com](), [io](), [parallel](), [plan](), [postgresql](), [speed](), [timing](), [uncategorized](), [worker]() ### AI overview This article explains how PostgreSQL explain plans can report per-worker and global I/O bandwidth during parallel execution. It describes how summed worker timings differ from wall-clock time and introduces an exclusive-time bandwidth figure for the disks' total workload. ### Source excerpt Jeremy Schneider suggested a change to how plans are displayed - adding another bit of information in case we have timing information for IO for explain node. Took me a while to research, but it finally made it's way... Let's consider this simple plan. In it's Parallel Seq Scan node we see: -> Parallel Seq ... Continue reading "Per-worker, and global, IO bandwidth in explain plans" ## Promise based Web Worker Messaging DevFeed: [Promise based Web Worker Messaging]() Original publisher: [Read original article]() Author: Stanko Published: 2025-11-03T00:00:00Z Content type: tutorial Language: en Sources: [Stanko Tadić]() Topics: [Promise](), [Messaging](), [Web](), [async/await](), [Code](), [Error Handling]() Tags: [async](), [await](), [code](), [error-handling](), [event](), [implementation](), [messaging](), [thread](), [web](), [worker]() ### AI overview This tutorial presents a Promise-based wrapper for Web Worker messaging. It explains how unique message identifiers map worker responses to stored promises, allowing the main thread to resolve or reject the corresponding promise and use async/await with simpler error handling. The same pattern can also be applied to Service Workers. ### Source excerpt If you've ever used Web Workers (or any other event-based communication), you probably noticed that this kind of code can be hard to read and reason about. You also have to implement some kind of identifier for each message to recognize which worker response corresponds to which request. To simplify that, we can write a small wrapper that lets us use Promises to communicate with Workers. I'll show you an example for Web Workers, but the same pattern can be applied to Service Workers as well. The resulting API looks like this: const workerResponse = await sendToWorker(data); I first used this approach in Pulsar, because I wanted to parse and execute the user's code in a Web Worker, but also wait for the worker to finish before providing data for the next frame. Implementation # The idea is fairly simple - before sending a message to the worker, we create a unique id and a promise. We store the promise in a map using the id as the key. Then we send an event to the worker, including both the data and the id, and return the promise to the caller. When the worker finishes its calculation, it sends back a message that includes the result and the same id. In the main thread, we listen for these messages. When one arrives, we use the id to find the corresponding promise in our map. Finally, based on the worker's result, we resolve or reject that promise. It might sound like a lot, but the code is actually quite straightforward: send-to-worker.jsCopy // Worker initialization const worker = new Worker("./path-to-your-worker.js"); // Map of promises const promises = {}; worker.addEventListener("message", (e) => { // Listen to worker messages and find the correct promise matching the id // Then resolve or reject it depending on the response if (e.data.error) { promises[e.data.id].reject(e.data.error); } else { promises[e.data.id].resolve(e.data.data); } // Remove the resolver reference delete promises[e.data.id]; }); // For identifiers it is safe to use a simple integer // whic ## How to convert your job scheduling system to Temporal Schedules DevFeed: [How to convert your job scheduling system to Temporal Schedules]() Original publisher: [Read original article]() Author: Irina Belova Published: 2024-04-15T04:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [Job](), [migration](), [systems](), [retry](), [Script]() Tags: [how-to](), [job](), [migration](), [replacement](), [retry](), [scheduling](), [scripts](), [worker](), [workflow]() ### AI overview This tutorial explains how to migrate existing cron and other scheduled jobs to Temporal Schedules. It covers wrapping non-Temporal scripts in Activities, assessing schedule and overlap requirements, handling retries and failures, and deploying workflows in a Temporal Worker. ### Source excerpt Temporal Schedules offer a reliable, efficient alternative to traditional job schedulers, replacing Cron, systemd timers, and task queues like Celery. ## An introduction to Worker tuning DevFeed: [An introduction to Worker tuning]() Original publisher: [Read original article]() Author: Fitz Published: 2023-10-23T07:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [Deployment](), [optimize](), [Processes](), [Server]() Tags: [caching](), [client](), [cloud](), [commands](), [deployment](), [how-to](), [metrics](), [performance](), [process](), [queues](), [requirements](), [server](), [streaming](), [temporal-concepts](), [types](), [using](), [worker](), [workers](), [workflow]() ### AI overview This guide explains how to tune Temporal Workers as workloads grow beyond a single Worker. It covers deployment patterns, important configurations, and Worker-side performance considerations for managing a Worker pool. ### Source excerpt Learn how to tune Temporal Workers for peak performance. Discover deployment patterns, key metrics, and configurations to optimize your Worker pool effectively. ## Python SDK: Diving into Workers and Workflows DevFeed: [Python SDK: Diving into Workers and Workflows]() Original publisher: [Read original article]() Author: Matt Bernier Published: 2023-03-07T17:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [Python](), [SDKs]() Tags: [client](), [python](), [sdk](), [temporal-concepts](), [worker](), [workflows]() ### AI overview A practical guide to the Temporal Python SDK that breaks a basic hello-world application into a workflow, activity, client, and worker. It explains how to structure the code across multiple files, pass data with a Python dataclass, register activities and workflows, handle nondeterministic operations, and return activity results. ### Source excerpt Go through each part of the basic hello world application: a workflow, an activity, a client, and a worker. ## Creating a Reverse Proxy for Partytown with AWS Cloudfront DevFeed: [Creating a Reverse Proxy for Partytown with AWS Cloudfront]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2022-02-18T15:49:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [Amazon Web Services](), [proxy](), [Cross-origin resource sharing (CORS)](), [JavaScript](), [Library]() Tags: [aws](), [cloudfront](), [cors](), [create](), [easily](), [insights](), [javascript](), [learn](), [library](), [party](), [partytown](), [performance](), [performantly](), [proxy](), [quickly](), [reverse](), [reverse-proxy](), [scripts](), [third-party](), [tracking](), [worker]() ### AI overview A tutorial on creating an AWS CloudFront reverse proxy for Partytown so third-party tracking scripts can run in a web worker. It explains that some scripts require a reverse proxy because their origins do not provide permissive CORS headers. ### Source excerpt Learn how to quickly & easily create a reverse proxy with AWS Cloudfront for Partytown, so your third party tracking scripts can run performantly in a web worker ## Metronomes in JavaScript DevFeed: [Metronomes in JavaScript]() Original publisher: [Read original article]() Author: Monica Dinculescu Published: 2019-09-10T00:00:00Z Content type: article Language: en Sources: [Monica Dinculescu]() Topics: [JavaScript](), [Latency](), [Code](), [async]() Tags: [async](), [javascript](), [latency](), [worker]() ### AI overview An experiment compares three JavaScript approaches to scheduling metronomes: running timing code on the main thread, using a Worker, and using the Web Audio clock. The article focuses on how blocking and latency affect accurate musical timing. ### Source excerpt My job nowadays involves a lot of music and JavaScript. You know what musicians really care about? Paychecks (support your local musicians, go to concerts, don't steal music from indie musicians). But also: keeping time. Keeping time in JavaScript is kind of a joke, not just because time is a social construct (this is the Jenn Schiffer social engineering at work), but because it's really easy to write code that blocks the timekeeper. Remember: JavaScript inherently only has one thread, which it uses for everything: painting your buttons, looping through arrays, mining bitcoin, scrolling. Everything. This means that most of the time, you write blocking code, but it only blocks for a little bit - 1ms here and there. And that's ok! Visually you don't notice that kind of latency, and let's be honest: it takes like 400ms to download the scripts, what's 1ms? 1ms starts getting in the way when it's actually 5ms, or 40 ms, or when you're trying to have a metronome run correctly. I made a typing delay experiment to see how much delay people could tolerate, and just for typing alone some people got really antsy around 200ms (shout out to the section of the population who thought they were heroes because they could tolerate infinity delay because of how bad ssh latency is. That's not heroic, that's Stockholm syndrome. Complain to your sys admins). When I changed that to an audio delay experiment, musicians started complaining around 40ms. And that was just audio delay, not an actual metronome. Imagine that fucking with your audio too! So, keeping time is really important - but how do we actually do that in JavaScript? In general, when we want to not block in JavaScript (and do better than setInterval, who is the friend you invite to a party but shows up like +/- 4h to it), we do one of two things: start writing async functions, or move code to a Worker (Surma has a great article about workers everyone should read). In particular, for audio things, there's a third option: using ## Congratulations! Now you are a remote worker. Enjoy your new life! DevFeed: [Congratulations! Now you are a remote worker. Enjoy your new life!]() Original publisher: [Read original article]() Author: Junior Grossi Published: 2018-04-02T03:00:52Z Content type: opinion Language: en Sources: [Junior Grossi]() Topics: [Job](), [digital]() Tags: [careers](), [developers](), [interviews](), [job](), [productivity](), [programming](), [remote](), [remote-work](), [remote-working](), [work](), [work-from-home](), [worker]() ### AI overview This personal commentary describes the early experience of becoming a remote worker, from interviews and accepting a job offer through the first months of working from home. It emphasizes perceived gains in productivity and quality of life during the initial four to five months. ### Source excerpt Working remotely is the dream job of most developers I know. It's a hard process but it's totally possible. Now you got the best job you could . Enjoy your new life! The beginning. The dream. Do you remember yourself some weeks/months ago? The first interview you did (maybe you're not a native English speaker like ... Continue reading Congratulations! Now you are a remote worker. Enjoy your new life! ## PGQ Coop Consumers DevFeed: [PGQ Coop Consumers]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2012-03-12T13:43:00Z Content type: article Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Concurrent Programming](), [Job]() Tags: [batch](), [distributed](), [pgq](), [postgresql](), [queue](), [queues](), [replication](), [scale](), [worker](), [workers]() ### AI overview The article describes using PostgreSQL Queue (PGQ) for transactional batch processing in a high-scale architecture. It explains consolidating events from 1,280 source queues into five destination queues and using cooperative consumers to distribute processing across workers. ### Source excerpt While working a new PostgreSQL architecture for an high scale project that used to be in the top 10 of internet popular web sites (in terms of visitors), I needed to be able to off load some processing from the main path: that's called a batch job. This needs to be transactional: don't run the job if we did rollback; the transaction, process all events that were part of the same transaction in the same transaction, etc. ## Scaling Python Servers with Worker Processes and Socket Duplication DevFeed: [Scaling Python Servers with Worker Processes and Socket Duplication]() Original publisher: [Read original article]() Author: Chris Hager Published: 2011-01-29T00:00:00Z Content type: tutorial Language: en Sources: [Chris Hager]() Topics: [Python](), [Server](), [Concurrent Programming](), [Processes](), [Operating system](), [Serialization protocols]() Tags: [asynchronous](), [client](), [concurrent](), [cpu](), [processes](), [protocol](), [python](), [request](), [responses](), [scale](), [servers](), [tcp](), [threads](), [worker]() ### AI overview This tutorial explains how Python servers can scale by using worker processes that duplicate client sockets, allowing workers to process requests directly. It also introduces TCP server basics, serialization, the C10K problem, and asynchronous I/O for managing many clients. ### Source excerpt Developing servers that scale is usually quite tricky, even more so with Python and the absence of worker threads which can run on multiple cpu cores [1]. A possible solution are worker processes that duplicate the client's socket, a technique that allows the workers to processes requests and send responses directly to the client socket. This approach is particularly useful for long lasting connections with more than one request per session. ## Background writers DevFeed: [Background writers]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2010-07-19T14:30:00Z Content type: opinion Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Processes](), [Erlang](), [Finite-state machine]() Tags: [article](), [database](), [erlang](), [postgresql](), [processes](), [worker]() ### AI overview The article discusses proposals to generalize PostgreSQL background workers, building on the autovacuum process and related patches. It considers an extensibility API for external processes and workers, drawing ideas from Erlang supervision and finite-state-machine behaviors. ### Source excerpt There's currently a thread on hackers about bg worker: overview and a series of 6 patches. Thanks a lot Markus! This is all about generalizing a concept already in use in the autovacuum process, where you have an independent subsystem that require having an autonomous daemon running and able to start its own workers. I've been advocating about generalizing this concept for awhile already, in order to have postmaster able to communicate to subsystems when to shut down and start and reload, etc. Some external processes are only external because there's no need to include them by default in to the database engine, not because there's no sense to having them in there.