Microsoft is walking away from more products this year than it did in 2025. Products that still run on millions of devices, including Windows 11 24H2, Office 2021, SQL Server 2016, and Windows Server 2012’s last ESU year, all expire in 2026. While 2025 was mostly about Windows 10, 2026 is a pile-up.

Also, in case you didn’t know it already, once a product hits its date, security updates, bug fixes, and paid support stop, unless Microsoft happens to offer an Extended Security Updates program for it, and even ESU only covers critical security fixes, nothing else.

Note that this doesn’t mean a software becomes unusable. It just stops being protected. For a note-taking app, that’s alright. But for a database sitting behind your company firewall, the consequences can be devastating if you don’t do anything about it.

So, we went through Microsoft’s official 2026 lifecycle page, checked every date, and ranked all of it by how many people it hits and how bad the fallout. Here is the list of all important Microsoft products losing support in 2026:

#1 Windows 11 24H2 (Home and Pro) – October

Windows 11, version 24H2 for Home and Pro editions reaches end of servicing on October 13, 2026. Since 24H2 has been the default install on every new Windows 11 PC since October 2024, that covers most of the consumer install base.

To check which version you have, press Win + R, type winver, and press Enter.

However, Windows 11 24H2, 25H2, and 26H2 all run on the same platform, codenamed Germanium. As Windows Latest reported, Microsoft has already started force-installing 25H2 on eligible Home and Pro PCs to clear this exact deadline, and it takes minutes with one reboot.

Enterprise and Education editions get a reprieve until October 2027. Open Settings > Windows Update and check now. If 25H2 hasn’t landed yet, force it. There’s no real reason to wait.

#2 Office 2021 and Office LTSC 2021, all editions – October

This is not very good news for me, because when I bought my PC, it came with lifetime support for Office 2021, and the then-ignorant me didn’t realize that lifetime meant just 5 years! Unlike Windows versions, updating from one Office version to the next isn’t free.

Every version of Office 2021 dies on the same date as Windows 11 24H2. Word, Excel, PowerPoint, Outlook, Access, OneNote, Publisher, Visio, and Project 2021 all go, plus the Office 2021 LTSC builds for Windows and Mac. Microsoft lists all nine apps separately under the same October 13, 2026 retirement, and there’s no partial exemption.

Note that older perpetual releases like Office 2016 and 2019 got ten years of support. Anyone who paid once for Office 2021 specifically to dodge a Microsoft 365 subscription is now facing another purchase decision half as far apart as they’d probably budgeted for.

Home users and small businesses on the perpetual, non-subscription version of Office feel this. Of course, Microsoft 365 subscribers can ignore it, since their apps update on their own. Either way, the path forward is a Microsoft 365 subscription or buying Office LTSC 2024, which carries support through 2029!

#3 Windows Server 2012 and 2012 R2, final ESU year – October

Windows Server 2012 and 2012 R2 left mainstream support in October 2023, and Microsoft sold organizations three more years of Extended Security Updates as a bridge. Come October 13, 2026, that bridge is closing. There’s no ESU Year 4 coming.

Windows Server 2012 still runs a lot of domain controllers, file servers, and business-critical apps that never got scheduled for migration. Server operating systems tend to outlast the hardware refresh cycles built around them, and 2012 has had an unusually stubborn tail.

Any organization still running the 2012 family in production is exposed, particularly on premises rather than in Azure. (Azure-hosted instances get ESU coverage for free during this same window, a detail plenty of admins seem to miss.) The way out is migrating to Windows Server 2025 or moving the workload into Azure Virtual Machines to keep security coverage without a separate ESU bill.

#4 SQL Server 2016 – July

SQL Server 2016 hits extended end of support on July 14, 2026. It’s the biggest database deadline on the calendar this year. SQL Server 2016 has quietly become a workhorse release, under ERP systems, reporting infrastructure, and countless custom apps that nobody had urgent reason to touch.

Microsoft does sell Extended Security Updates for up to three more years after the cutoff, but only to organizations that plan for it. And the catch is that ESU Year 1 pricing starts July 15, 2026, and covers only what Microsoft classifies as critical severity, not the broader range of fixes a fully supported version gets.

Any business still running production workloads on SQL Server 2016 needs a plan, especially in regulated industries like healthcare and finance, where unsupported database software is also a compliance problem. Upgrading to SQL Server 2019 or 2022 works, and so does migrating to Azure SQL Database or Azure SQL Managed Instance, where Microsoft handles the patching for you.

#5 SharePoint Server 2016 and 2019, plus Project Server 2016 and 2019 – July

Same date as SQL Server 2016. SharePoint Server 2016 and 2019 both reach end of extended support on July 14, 2026, alongside Project Server 2016 and 2019, according to Microsoft.

Organizations that built custom intranets, document workflows, or records management systems on top of on-premises SharePoint may be affected. SharePoint Online has kept gaining features for years while the Server editions were frozen in time, so Microsoft isn’t cutting off something current here. They’re closing a door most admins already saw coming.

Enterprises and government agencies running on-premises SharePoint farms may feel the most heat, especially since data sovereignty rules make a full cloud move practically unfeasible. Migrating to SharePoint Server Subscription Edition keeps things on-premises with continued support, while moving to SharePoint Online under Microsoft 365 is the other route.

#6 Microsoft Publisher – October

Publisher is the odd one out in this list, because apart from losing support this year, it’s being retired. Microsoft’s support page confirms Publisher drops out of Microsoft 365 after October 2026, and subscribers lose the ability to open or edit Publisher files once that happens.

Of course, the perpetual, locally installed version keeps technically running past the cutoff since it’s within Office LTSC 2021’s support window, but it stops receiving updates, and Microsoft has already pulled it from sale. There’s no Publisher 2024. Microsoft’s suggested alternatives are Word and PowerPoint for layout work, which says plenty about where the company sees this product going.

Small businesses, churches, and community groups that still use Publisher for newsletters and brochures are the affected group here, a surprisingly loyal user base for software most people assumed died a decade ago. We recommend converting existing .pub files to PDF or Word before the cutoff.

#7 Exchange Server and Skype for Business Server, ESU Period 2 – October

Exchange Server 2016 and 2019 technically reached end of support in October 2025, but Microsoft split the paid Extended Security Updates bridge into two periods to soften the blow. Period 1 expired in April 2026. Period 2, which is the real final cutoff, runs out on October 31, 2026. Skype for Business Server 2015 and 2019 follow the identical two-period schedule.

Once Period 2 closes, that’s the end of the line. No more ESU purchases for either product!

Organizations still running on-premises email or unified communications that haven’t migrated to Exchange Online or Teams need to move now. Exchange Online under Microsoft 365 is the cloud path, while Exchange Server Subscription Edition is the option for anyone who has to stay on-premises.

#8 Windows 11 Enterprise and Education 23H2, plus .NET 8, .NET 9, and PowerShell 7.4 – November

Four unrelated products share this one date. Windows 11 Enterprise, Education, and IoT Enterprise editions on version 23H2 reach end of servicing on November 10, 2026, a year after Home and Pro editions of the same version lost support back in November 2025. With it, .NET 8 (an LTS release), .NET 9 (a Standard Term Support release), and PowerShell 7.4 (also LTS) all hit end of support the same day, confirmed directly on Microsoft’s lifecycle page.

IT teams managing Windows 11 23H2 fleets on enterprise licensing need to move, along with developers with apps still targeting .NET 8, .NET 9, or PowerShell 7.4. Upgrade managed Windows devices to 24H2 or later, move .NET apps to .NET 10, and update PowerShell to 7.6 or newer.

#9 Windows 10 2016 LTSB and IoT Enterprise LTSB 2016 – October

The 2016 Long-Term Servicing Branch editions of Windows 10 reach end of extended support on October 13, 2026. LTSB and its successor LTSC, exist specifically for kiosks, medical devices, and industrial equipment that need a locked-down OS with no feature churn for a decade at a stretch.

Manufacturers and healthcare providers using specialized hardware on the 2016 LTSB branch are a narrower audience than mainstream Windows 10, but a higher-stakes one. A migration to a currently supported LTSC release is the only real path, since these devices rarely click through a Windows Update prompt.

#10 Windows 11 SE – October

Windows 11 SE, the stripped-down education edition built to go after Chromebooks, loses support on October 1, 2026. Microsoft confirmed back in 2025 that no further updates were coming and has been nudging schools toward standard Windows 11 editions. As expected, the $250 Surface SE that launched alongside it isn’t getting a successor either.

Schools and districts that bought into the Windows 11 SE and Surface SE ecosystem are stuck with a bet Microsoft seems to have given up on. Moving managed devices over to standard Windows 11 Education or Windows 11 Pro Education licensing is the only supported way forward.

#11 Dynamics CRM 2016 and older Dynamics products – January

Dynamics CRM 2016, along with Dynamics GP 2016, GP 2016 R2, NAV 2016, and C5 2016, all lost support in the first third of the year. Dynamics CRM 2016 went first, on January 13, 2026, with the GP, NAV, and C5 2016 releases that followed on April 14, 2026.

Businesses running on-premises CRM or ERP on these specific 2016-era Dynamics products, mostly mid-market companies that never made the jump to Dynamics 365’s cloud model, had to migrate to Dynamics 365 Business Central or the relevant cloud Dynamics 365 app.

#12 Microsoft Configuration Manager, version 2409 – June

Configuration Manager 2409 reached end of support on June 6, 2026. ConfigMgr runs an 18-month rolling support window per release, so this is routine stuff, but IT admins still stuck on the 2409 branch had to update before the date to keep getting fixes. Moving to 2503 or later through the standard ConfigMgr update path cleared it.

#13 Visual Studio 2022 LTSC channels, versions 17.10 and 17.12 – January and July

Visual Studio 2022‘s Long-Term Servicing Channel builds have staggered end dates through the year. Version 17.10 LTSC lost support on January 13, 2026, and 17.12 LTSC follows on July 14, 2026. The LTSC channel exists so development teams can freeze their tooling on purpose, so these dates mostly come to teams that deliberately opted out of the mainstream release train and need to move to a currently supported LTSC channel, or switch to mainstream servicing.

#14 InfoPath 2013, SharePoint Designer 2013, and legacy virtualization tools – April and July

A cluster of older Microsoft tools wind down through the middle of the year. Microsoft Application Virtualization 5.0 and 5.1, Microsoft BitLocker Administration and Monitoring, the Diagnostics and Recovery Toolset, and User Experience Virtualization all ended April 14, 2026. InfoPath 2013 and SharePoint Designer 2013 follow on July 14, 2026, the same day as the SharePoint and Project Server retirements above.

Enterprises still running App-V for application virtualization, or teams that built forms and workflows in InfoPath and SharePoint Designer instead of Power Apps and Power Automate, are the ones with work to do. Migrating InfoPath and SharePoint Designer workflows to Power Platform is something Microsoft has been pushing for years anyway. The virtualization tools mostly point toward modern app deployment options inside Configuration Manager instead.

#15 Azure service retirements – September and October

A handful of Azure AI and infrastructure services shut down within weeks of each other. Azure Anomaly Detector, Azure Metrics Advisor, and Azure Personalizer all retire October 1, 2026, while Azure API for FHIR and Azure FXT Edge Filer go September 30, 2026.

Developers who built applications against these Azure AI services (a small but technically committed crowd) are the ones affected, since Microsoft has spent the last two years steering everyone toward Azure AI Foundry and Azure OpenAI instead. FHIR workloads move to Azure Health Data Services, while Anomaly Detector, Metrics Advisor, and Personalizer workloads have nearest equivalents waiting in Azure AI Foundry.

So, should you be worried?

Although I made this into just fifteen entries, the real count runs past fifty if we dismantle every Office app, Dynamics variant, and individual Azure. Yes, that’s a very large number, even for a software giant like Microsoft.

Windows 11 24H2 and Office 2021 hit the widest audience by far. SQL Server 2016 and the July server cluster may have the biggest business risk. Everything past that is not as big a deal as it seems.

Microsoft has a habit of stacking its biggest deadlines into the same two windows every year, mid-July and mid-October. Whatever you’re running, it’s worth checking against Microsoft’s lifecycle page directly instead of procrastinating over a few more months.

The post Microsoft is killing 15 products in 2026, including Windows 11 24H2 and Office 2021 appeared first on Windows Latest

Read more of this story at Slashdot.

When emailing out Outlook Meeting Invites to groups of people who don’t know each other, you may not want their email addresses exposed on the To: line of the Outlook invite to maintain the privacy of those you’ve invited – especially if the invitees are from different organizations.

Additionally, for Teams Meetings, you may want to hide the identities of the people that have joined so others can’t see their names or email addresses.

Both of these privacy-protecting features are available through Microsoft 365.

HIDE ATTENDEE LIST IN OUTLOOK MEETING INVITE

To “Hide Attendee List” for an Outlook Meeting Invite to protect customer privacy, you MUST first use “Outlook Web Access” or the “New Outlook”.

1. Create the Outlook meeting from the Outlook Web/New Outlook Calendar.  (Again, you cannot do this from “Classic Outlook”)
2. Turn on the “Teams Meeting” switch.
3. Enter in the attendee names in the Attendee field
4. Click the dropdown next to the Attendees field and select “Hide attendee list”

Now customers will only see their email address in the To: line when they receive the invite.

HIDE ATTENDEES NAMES DURING TEAMS MEETING
(Hide attendee names in Microsoft Teams meetings and webinars)

Before you SEND, you should also “Hide attendee names” in the actual Teams Meeting options for customer privacy during the meeting.

1. Go the Outlook meeting from the Calendar from “Outlook Web Access” or the “New Outlook”.
(You cannot do this from “Classic Outlook”)

2. Go to the Click the “Options” button for the Teams Meeting.

3. Under “Roles”, set “Who can present” to “Only organizers and co-organizers”

4. Under “Participation”, turn on “Hide attendee names”

Now customers will not see other attendee’s email addresses/identities. They will only see their own email address & the identities of the Presenters/Organizers.

The allure of emerging technology is undeniable, but adopting it rarely means completely ripping out what already works. Instead, new capabilities must find their place alongside existing infrastructure, complementing the systems that teams depend on daily. 

Model Context Protocol, or MCP, has generated significant buzz over the past year and a half, with some drawing parallels between the onset of this technology and traditional APIs. 

MCP and APIs offer two ways for engineers to create interconnected ecosystems. But for incident management teams, the terms are not interchangeable; each has a distinct role. 

Tool sprawl poses an ongoing challenge in incident management. A disconnected and fragmented approach prevents AI investments from delivering on their potential, resulting in a subpar experience for incident responders. 

MCP provides a consistent route to overcome this fragmentation while APIs continue to provide the deterministic control needed for repeatable workflows. 

Let’s explore both technologies and weigh the strengths and weaknesses of each as they apply to incident management.

Understanding the fundamentals

APIs provide structured endpoints that let one system request data from another or trigger specific actions. When a team’s monitoring tool queries the database for metrics or when a CI/CD pipeline tells the deployment service to roll out new code, that’s an API at work. 

MCP represents a different strategic approach. It’s a protocol designed specifically for connecting AI assistants and agents to external data sources and tools ( including other AI tools) through a standardized interface.

MCP doesn’t replace APIs. It creates a standardized layer through which AI agents can access the context they need from multiple tools and vendors. In incident management, cross-tool access is crucial. Responders need a connected view across alerts, changes, communications, service ownership, and customer impact.

“MCP doesn’t replace APIs. It creates a standardized layer through which AI agents can access the context they need from multiple tools and vendors.”

Here’s a summary of the differences between these two concepts and some pros/cons of each:

APIs for deterministic workflows

For incident management, APIs work best for repeatable actions that must be fast and consistent, even at high volume. Another way to think about it is in terms of deterministic workflows. Incident response teams want fast, certain action with no wiggle room for AI interpretation, especially during the mitigation phase. MCP may introduce unnecessary risk.

API-based integrations also help organizations meet security requirements via explicit authentication flows, detailed audit logs, and granular permission controls – critical insight for SOC2 compliance. While MCP can use the same authorization and permissions the APIs already have, teams need an extra layer of safety with a human in the loop because an AI agent is choosing what to run.

MCP for non-deterministic paths

MCP becomes compelling when human operators interact with systems through natural language, especially during triage, diagnosis, and investigation. These are the moments where responders need to gather context from across the stack, but are slowed down by tool sprawl. MCP gives AI agents a standardized way to access distributed context, creating a strategic advantage over agents operating in isolation. 

“MCP becomes compelling when human operators interact with systems through natural language, especially during triage, diagnosis, and investigation.”

For example, teams can ask, “Why are checkout errors spiking in the EU?” The AI agent can pull current incident details from the incident management platform, including event data from monitoring tools, recent change events and incident history, and information and stakeholder updates from collaboration tools like Slack or Microsoft Teams. With this context gathered and available in a single place, it’s far easier to surface likely contributing factors or hypotheses, as well as next best steps to verify.

MCP also excels in dynamic, exploratory scenarios where the sequence of steps is user-driven and approved rather than predefined. Requests can include “Post a status update about the checkout issue to our comms channel and add a quick note about impacted business services to the incident.” The agent can do both without the engineer leaving their tool of choice. It proposes a draft, checks with a human before posting, and then completes the actions upon approval.

The world will change

MCP may well represent how technical systems interconnect in an AI native future. As organizations increasingly rely on AI assistants for operational work, standardization and interoperability become invaluable.

For incident management, MCP offers a path to help teams realize greater strategic value from their AI investments by giving agents access to richer context, making them more powerful than when acting in isolation, reducing tool sprawl, and improving the responder experience.

The post APIs aren’t dead. Here’s where MCP fits alongside them. appeared first on The New Stack.

Editor’s Note: This article contains an exclusive excerpt from Latency by Pekka Engberg, which helps readers diagnose latency problems and master the low-latency techniques that have been predominantly “tribal knowledge” until now. You can download three chapters for free from ScyllaDB. And if you really want to geek out on latency, join the community at P99 CONF (free and virtual). 

Asynchronous processing is a powerful technique for improving system concurrency and hiding latency in systems where further latency reduction is impractical or impossible. By performing I/O operations asynchronously and deferring noncritical work, you can significantly improve perceived responsiveness because end users don’t perceive the latency. Whereas techniques like partitioning, caching, and other latency optimizations can reduce absolute latency, asynchronous processing offers a complementary strategy—it hides latency by allowing the system to remain responsive even when some operations take time.

“Asynchronous processing offers a complementary strategy—it hides latency by allowing the system to remain responsive even when some operations take time.”

In this article, we’ll explore the fundamental differences between synchronous and asynchronous processing, examine how the event loop enables efficient async execution, and investigate the key challenges and tradeoffs that async systems must address.

Asynchronous vs. synchronous processing

Asynchronous processing enables tasks to execute independently and in overlapping periods, unlike synchronous processing, where tasks run in sequence. In other words, in a synchronous system, a task is executed to completion before the next one can begin. For example, suppose a single-threaded synchronous server is reading and processing messages. It first reads a message from a socket, which may require the thread to block until the message fully arrives. The server then processes the message, and it finally sends a response before starting to process the next message. If request processing takes a long time or blocks, the system waits synchronously.

Asynchronous processing removes this constraint, allowing multiple tasks to pro­gress simultaneously. For example, a server using asynchronous processing can process multiple independent requests concurrently by using I/O multiplexing, an operating system (OS) interface, to poll for the status of various connections. The server can then react to events, such as the socket becoming readable or writeable, to process a request. Similarly, the asynchronous server can initiate sending a response over the network and then work on other tasks without waiting for the response.

Asynchronous processing is similar to concurrent programming. However, asynchronous processing differs from concurrent programming because it has explicit interfaces. For example, concurrent programming using threads allows a server to synchronously process a request while retaining concurrency by context-switching between threads. The server executes the send() and recv() system calls, which block if there’s nothing to read from a socket or the socket is not writeable. When the server blocks, the OS switches to another thread for concurrent execution. In contrast, with asynchronous processing, the server uses an I/O multiplexing interface to poll for socket state. The I/O multiplexing interface tells the server what sockets are readable, and the server can read from them without blocking the thread. Similarly, when the server sends a response, it uses an asynchronous interface to send the response, but it can then immediately continue work without blocking, letting the OS send the response in the background.

Figure 1 illustrates the difference between synchronous and asynchronous processing (which are also summarized in the sidebar titled “Differences between asynchronous, concurrent, and parallel processing”). In this example, we have two tasks, A and B, that must run to finish our work in full. Suppose a backend system needs to communicate with external systems A and B to complete a request it has received. In synchronous processing, each task must finish before the next one starts. We run task A until it is complete, including the I/O it submits, and then run task B. The total time needed is the time of all tasks added together. If a backend service needs to do all these tasks, users must wait for this total time to get their response.

However, in asynchronous processing, we can perform the I/O for task A simultaneously with task B, and we are finished when both of them are done. If the I/O runs simultaneously, the wait time is much shorter for users, even though each task still takes the same time. This works well in backend services when making database calls or calling other services because these tasks can run independently without blocking each other. But there’s a catch: if your I/O can’t run in parallel, using asynchronous processing won’t help but could instead make things run slower because managing async tasks adds extra work for the system.

Asynchronous processing is also a critical technique for hiding latency. Some operations take a long time to complete, despite your best efforts to reduce latency, so it is essential to perform operations without everyone having to wait for them to complete. For example, backend systems typically interact with external systems like third-party services, database servers, and message queues, where each interaction adds some latency. With synchronous processing, you often build systems that don’t exploit the inherent parallelism available and that cause idle time where you’re waiting for systems to complete their work. In contrast, async processing allows you to minimize wait time by starting operations asynchronously and reacting when they are complete.

In synchronous processing, you structure your code as a sequence of operations that depend on each other. For example, a request processing function for a synchronous server might look something like the following.

Listing 1 A simple example of a synchronous system

fn process_requests(socket: &Socket) {
  loop {
    process_request(socket);
  }
}

fn process_request(socket: &Socket) {
  let msg = socket.recv();
  let request = parse_message(msg);
  let resp = match request {
    Request::GetUserInfo(id) => get_user_info(id);    
  };
  let resp = format_response(resp);
  socket.send(resp);
}

At a high-level, we have the process_requests function, which processes any incoming requests from a socket. In the process_request function, each step is run to completion before we start another step. We read a message from the socket, we parse the message to determine what the request is, we process the request, and we finally send a response over the socket. More importantly, we don’t start another process_request until we’ve sent out a response, and we don’t allow requests to be processed from multiple sockets either.

While concurrency primitives like coroutines and futures enable parallel execution they’re insufficient for efficient asynchronous processing, particularly for I/O. You must structure the application differently if a server processes thousands of concurrent connections. The event loop is the foundation for efficiently multiplexing I/O operations across many connections.

The event loop

The event loop is the central coordinator for all input and output operations—it’s at the heart of an asynchronous system. While traditional synchronous programs handle one connection at a time—like a single worker processing tasks in sequence—an event loop operates as a dispatcher, simultaneously managing thousands of I/O operations. This architectural pattern, sometimes called an I/O loop or I/O dispatcher, is how asynchronous processing handles concurrent operations efficiently. Instead of dedicating separate resources to each connection, the event loop multiplexes various I/O sources—network connections, file operations, timers, and more—by tracking their states and processing them when they’re ready.

“The event loop is the central coordinator for all input and output operations—it’s at the heart of an asynchronous system.”

The event loop follows a simple yet powerful pattern:

1. Poll for events.
2. Process events.
3. Run scheduled tasks.
4. Repeat.

The event loop polls for events such as incoming data from a socket, an expired timer, or I/O completion by using OS-specific I/O multiplexing interfaces such as io_uring and epoll on Linux, kqueue on macOS, and IOCP on Windows. These interfaces let you register interest in an event source and get a notification when an event happens. For example, instead of reading data from a socket, the application expresses interest in a socket becoming readable. When data arrives from the network to the socket, the OS notifies the application, via the I/O multiplexing interface, that the socket is now readable. The event loop discovers this via polling and calls into the application’s event handling logic to process the newly arrived data from the socket.

Let’s implement a basic event loop in Rust to understand its structure better:

struct EventLoop {
    // Holds registered event sources like sockets, files, timers
    sources: Vec<EventSource>,    
}

impl EventLoop {
    fn run(&mut self) {
        loop {
            // Create a new collection to store events
            let mut events = Events::new();

            // Poll for new events with a timeout
            self.poll(&mut events, Duration::from_millis(100));

            // Process each event that was found
            for event in events.iter() {
                self.process_event(&event);
            }

            // Run any scheduled tasks
            self.run_scheduled_tasks();
        }
    }
}

The EventLoop::run() method demonstrates the core functionality of event-driven programming: continuously polling for and processing events. The poll() method uses an OS-specific I/O multiplexing interface, such as io_uring, for events on event sources. As you can see in the example code, we also specify a timeout for event polling. A timeout is needed because I/O polling in the event loop is often the only synchronous code that blocks the thread until an event happens. Polling can block if the system is idle and no events occur, and this blocking can reduce the wasted CPU cycles when there’s nothing to do. However, to ensure that the event loop does not block forever, the timeout ensures that we return from poll(). This allows the event loop to also perform work that is not conditional to an event, such as executing background work. However, in some cases, you might use busy-polling to avoid the sleep/wakeup cycle latency for some latency-sensitive event loops.

The process_event function is responsible for processing any events discovered during polling. For example, if the application registered interest in data arriving from the network (such as a socket becoming readable), the process_event function reads from the socket and forwards the data for the application to process. A simple process_event function might look something like this:

struct EventLoop {
    // Holds registered event sources like sockets, files, timers
    sources: Vec<EventSource>,    
}

impl EventLoop {
    fn run(&mut self) {
        loop {
            // Create a new collection to store events
            let mut events = Events::new();

            // Poll for new events with a timeout
            self.poll(&mut events, Duration::from_millis(100));

            // Process each event that was found
            for event in events.iter() {
                self.process_event(&event);
            }

            // Run any scheduled tasks
            self.run_scheduled_tasks();
        }
    }
}

As you can see, each event is represented by an Event enumeration with variants for different events. The event-processing logic is specific to how the event loop is structured. For example, if the event loop uses callbacks for event handling, it calls them, delegating work to the application. The application may then perform the work in the callback or submit the work to another thread for processing.

Figure 10.2 visualizes how the event loop performs work. In this example, work is split into three separate tasks:

1. Accept connection
2. Process request
3. Send response

The first task runs when the I/O multiplexer notifies the event loop that there is an incoming connection. The application reacts to the event by accepting the connection and then registering interest about when the accepted socket becomes readable. When data arrives from the network, the OS notifies the event loop that the socket is readable. The application reacts to this by reading from the socket and processing the incoming request. Finally, the application registers interest in the socket becoming writable. When the OS has enough buffer memory for an outgoing response, it notifies the application, which writes the response to the socket.

“While the event loop is the low-level infrastructure for asynchronous processing, you’ll also need some concurrency primitives to specify dependencies between individual tasks.”

If you contrast the event loop to a synchronous server, which you saw in listing 1, you’ll see two key differences between these approaches:

• Non-blocking operations—The event loop does not block the thread, but instead registers interest in events such as a socket becoming readable, and it defers reading from the socket until that condition is true, handling other events meanwhile.
• Resource efficiency—A single thread running an event loop can handle thousands of concurrent connections because it does not need to wait for I/O operations to complete. Instead, the I/O multiplexing OS interface allows the event loop to poll for the status of multiple event sources, such as sockets, at the same time, performing event-based processing.

While the event loop is the low-level infrastructure for asynchronous processing, you’ll also need some concurrency primitives, like callbacks or futures to specify dependencies between individual tasks.

Challenges

While asynchronous processing can significantly improve application performance, it comes with several important pitfalls to consider:

• Complexity—Asynchronous code is generally more complex than synchronous code. You need to carefully manage task dependencies, handle errors across multiple operations, and deal with race conditions.
• Resource management—Running many tasks simultaneously can consume significant memory and system resources. You need to implement proper throttling and resource management.
• Debuggability—When something goes wrong in asynchronous code, it can be harder to track down the issue because the execution order isn’t always obvious, and stack traces might not tell the whole story.
• Error handling—With multiple operations running independently, error handling becomes more complex. You need to decide how failures in one task should affect other running tasks.

The post How async processing hides latency and improves responsiveness appeared first on The New Stack.

I keep running into the same slow-motion mess. Somebody hands me an OpenAPI definition that is supposed to be the single source of truth, and when I open it up half the operations are wearing three or four layers of vendor extensions they never asked for. There is an x-amazon-apigateway-integration block bolted onto every path because that is how the gateway got deployed. There is an x-speakeasy-name-override sprinkled around because someone was tired of the SDK method names. There might be a Kong plugin hint or two in there for good measure. None of that is the API. It is scaffolding for the tools that consume the API, and it has crept into the canonical spec until nobody can tell the contract from the build config anymore. Delete the wrong x- field and you break the pipeline. Keep it and you are shipping your infrastructure choices as part of your public interface.

This is exactly what OpenAPI Overlays are for. The whole point of an overlay is that you leave the canonical definition clean and describe your modifications as a separate document that gets applied at build time. So instead of one polluted spec, I keep the pristine Products API definition as the source of truth, and I keep one overlay per tool that needs its own metadata. The gateway gets its overlay. The SDK generator gets its overlay. The AI consumer, if it needs vendor hints, gets its own too. The source never learns any of their names.

Here is the gateway overlay. It reaches into the Products API definition and injects a rate-limit vendor extension onto the two collection operations that need throttling metadata.

overlay: 1.1.0
info:
  title: AWS API Gateway rate-limit extensions for Products API
  version: 1.0.0
extends: https://raw.githubusercontent.com/api-evangelist/products-api/main/openapi/products-api-openapi.yml
actions:
  - target: $.paths['/products'].get
    update:
      x-amazon-apigateway-integration:
        type: aws_proxy
        httpMethod: POST
        passthroughBehavior: when_no_match
  - target: $.paths['/products'].post
    update:
      x-amazon-apigateway-throttle:
        rateLimit: 20
        burstLimit: 40

The extends field points at the canonical raw URL, so the overlay is permanently bound to the real spec rather than a copy. Each action carries a JSONPath target that selects a specific operation — GET /products and POST /products here — and an update block whose contents get merged onto whatever the target resolves to. Because update is a merge, I am adding the x-amazon-apigateway-integration and throttle extensions without touching the parameters, responses, or the Product schema that already live on those operations. The AWS API Gateway import reads those extensions; my source definition never has to.

Now the SDK overlay, aimed at a completely different tool with completely different needs.

overlay: 1.1.0
info:
  title: Speakeasy SDK naming hints for Products API
  version: 1.0.0
extends: https://raw.githubusercontent.com/api-evangelist/products-api/main/openapi/products-api-openapi.yml
actions:
  - target: $.paths['/products/{id}'].delete
    update:
      x-speakeasy-name-override: deleteProduct
  - target: $.paths['/products/{id}/cancel'].post
    update:
      x-speakeasy-name-override: cancelProduct
      x-speakeasy-group: products

Same structure, same extends anchor, but this one speaks Speakeasy. It targets the DELETE /products/{id} and the cancel operation and drops x-speakeasy-name-override on each so the generated SDK exposes deleteProduct() and cancelProduct() instead of whatever the raw operationId would have produced, plus an x-speakeasy-group to bundle them. This is naming ergonomics for one specific codegen tool, and it has no business being in a definition that Kong or AWS or a documentation renderer also has to read.

The reason this pattern holds up is that overlays are composable. Each of these is a standalone document defined by the Overlay specification, and I can apply them in sequence — canonical spec, then gateway overlay, then SDK overlay — to produce a build-time artifact tailored to exactly one consumer, then throw that artifact away. Nothing accumulates in the source. When Speakeasy changes an extension name, I edit one file that only Speakeasy cares about. When I move off AWS to Kong, I delete a gateway overlay instead of surgically extracting x- fields from every operation and praying I got them all. This is one of the more underrated entries in the many use cases for overlays, and it is the one I reach for most.

Here is my take: if your canonical OpenAPI knows the name of your gateway, your SDK generator, or your codegen tool, you do not have a source of truth — you have a build artifact that got promoted by accident. Vendor extensions are real and useful, but they describe how a specific tool should treat your API, not what your API is. Put them in overlays, keep them out of the spec, and let the source stay the one thing every tool can agree on.