# Homegate Engineering Blog - Medium SMG | Homegate | ImmoScout24 Engineering is happy to share ideas and technologies used in daily work. Our goal is to provide a great experience in offering and finding a new home. - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Build a self-hosted, GPU-accelerated translation API with open-source LLMs DevFeed: [Build a self-hosted, GPU-accelerated translation API with open-source LLMs]() Original publisher: [Read original article]() Author: fm.mateo Published: 2025-08-07T12:57:31Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Low Latency](), [Large Language Model](), [Cloud](), [Google Cloud Platform (GCP)](), [GPU](), [Inference](), [Open Source](), [Self-hosted](), [API](), [Back end](), [Monitoring](), [Tooling]() Tags: [ai](), [amazon](), [api](), [backend](), [cloud](), [cost](), [deepl](), [energy](), [google-translate](), [inference](), [infrastructure](), [latency](), [low-latency](), [machine-translation](), [monitoring](), [open-source](), [tooling](), [translation]() ### AI overview This step-by-step guide describes how Swiss Marketplace Group built and deployed a self-hosted, GPU-accelerated translation service using open-source large language models on Google Cloud Platform. The article reports over 85% cost savings, sub-three-second latency, and no impact on buyers' conversion rate compared with its previous DeepL API usage. ### Source excerpt Build a low-cost, low-latency, low-energy AI Translator: a DeepL alternative that worksA step-by-step guide to deploying your own AI-powered translation API at scale, and get rid of DeepL, Google Translate, Amazon Translate, etc.Introduction and motivation At Swiss Marketplace Group (SMG), we operate multiple online platforms used daily by millions of people across Switzerland. One of them, Ricardo, is a second-hand marketplace where buyers and sellers interact in four different languages: French, German, Italian, and English. To deliver a seamless experience across languages, we had been relying on DeepL API, one of the most accurate translation APIs on the market. And while DeepL served us well in terms of quality and response time, it came with significant downsides: A monthly cost of over 7,000 CHF A black-box approach, offering no insight into how translations were produced Data privacy risks As usage grew, so did the bill, and the urgency to reduce it. Around that time, generative AI had made enormous improvements, and open-source large language models (LLMs) had become more accessible than ever. This sparked a question: Can we replace DeepL API with a self-hosted open-source LLM, without sacrificing translation quality, speed, and user experience? The answer turned out to be yes. Over the course of my master thesis, I built a production-grade, GPU-accelerated translation service using modern LLM tooling, hosted entirely on Google Cloud Platform (GCP), and fully integrated into Ricardo's infrastructure. The result: Over 85% cost savings Sub-3-second latency No impact on conversion rate of buyers And everything is reproducible, transparent, and extensible. In this article, I'll walk you through exactly how I built it, from selecting the right model, optimizing inference time, and wrapping it in an API, to deploying and monitoring it in production. My goal is simple: enable you to do the same. Whether you're a backend developer, a ML engineer, or just AI-curious ## Replacing AWS Step Functions with SQS FIFO queues and cutting the cost in half DevFeed: [Replacing AWS Step Functions with SQS FIFO queues and cutting the cost in half]() Original publisher: [Read original article]() Author: Alexei Liulin Published: 2025-03-14T14:47:27Z Content type: article Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Amazon Simple Queue Service (SQS)](), [AWS Step Functions](), [Amazon Web Services]() Tags: [aws](), [aws-step-functions](), [batching](), [cloud-computing](), [cost](), [cost-optimization](), [email](), [fifo](), [lambda](), [notifications](), [push-notifications](), [queue](), [sqs](), [sqs-queue](), [workflow]() ### AI overview The article describes SMG Real Estate's Search Alerts system, which batches property-match notifications for delivery by email or mobile push notification. It explains the original AWS Step Functions implementation and its transition-cost problem, motivating a more cost-efficient approach using SQS FIFO queues. ### Source excerpt One of the core services for SMG Real Estate is Search Alerts -- a service that allows users to be notified about new properties published on ImmoScout24 and Homegate. For example, if a user is looking for a new apartment having N rooms and costing less than X, and not finding any matches now, they can create a search alert with those search criteria. When a new property matching those criteria is published, the user will be notified either via email or a mobile push notification. About the Search Alerts system Users can choose the frequency of notifications -- either every 5 minutes or every 4 hours (assuming there are any to be delivered). The vast majority of search alerts are configured with the 5-minute frequency. Just to get an idea of the scale, we have: Millions of published properties match saved search alerts every day More than a million emails and push notifications sent daily Check out our "Homegate's fast and modern search experience helps users find their dream home" blog post for an overview of how Search Alerts work. The Original Implementation In the original implementation we used an AWS Step Function to achieve the 5- minute batching of notifications: When a new property matching a search alert arrived, the StartSendNotificationProcess lambda would start a Step Function execution specific to that search alert. All it did was waiting for 5 minutes while the matches accumulated in the matches-{searchAlertId} SQS queue, which was programmatically created for that specific search alert If more matching listings arrived during the 5-minute waiting period, the StartSendNotificationProcess lambda attempted to start the step function execution with the same name. When it failed with the ExecutionAlreadyExists error, we knew there was already a SF for waiting. That way the deduplication of notification processes was guaranteed. After 5 minutes of waiting time, the Step Function execution proceeded with triggering the LoadMatches lambda that received the acc ## AWS API Gateway's Request Validation: Navigating the Quirks DevFeed: [AWS API Gateway's Request Validation: Navigating the Quirks]() Original publisher: [Read original article]() Author: Thomas Klein Published: 2024-08-09T12:07:11Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Amazon API Gateway](), [Amazon Web Services](), [API](), [gateway](), [JSON Schema](), [TypeScript](), [configuration](), [enum](), [HTTP]() Tags: [api](), [api-gateway](), [aws](), [aws-api-gateway](), [aws-lambda](), [enum](), [gateway](), [handler](), [http](), [json](), [json-schema](), [middleware](), [middy](), [tests](), [type-safety](), [typescript](), [validation](), [zod]() ### AI overview This tutorial examines AWS API Gateway request validation. It explains that query-parameter presence is checked, but enum values may not be enforced, while POST and PUT payloads are validated with JSON Schema Draft 4. It also discusses generic error messages and TypeScript-based validation approaches. ### Source excerpt AWS API Gateway's request validation follows a specific set of rules that developers should be aware of when setting up their APIs. While it offers some validation features, it's important to understand its scope and limitations. Let's examine how it works with a common API configuration: parameters: - name: offerType in: query required: true description: RENT or BUY schema: type: string enum: - RENT - BUY With this configuration, API Gateway diligently checks for the presence of the query parameter, returning an HTTP 400 error if it's missing. However, it falls short when it comes to validating the actual value. Surprisingly, it would accept "KERMIT" without batting an eye, despite the clear enum specification. This behavior, while documented, can be a source of frustration for developers expecting more comprehensive validation. Interestingly, API Gateway shows more validation prowess with POST and PUT requests. It validates request payloads using JSON Schema Draft 4, demonstrating a somewhat inconsistent approach to input validation across different HTTP methods. Even when it does catch an error, API Gateway's feedback is less than illuminating. Instead of specific error details, you're met with a generic {"message": "Invalid request body"}. For more information, you'll need to dig into the associated log streams, which isn't ideal for surfacing error details in API responses. Example output in AWS console from a failed request validation when a body request validator is setup. API Gateway's validation is handy, but it leaves a lot to be desired. Developers often need to add extra checks for a truly robust API. While API Gateway supports various integrations and Lambda languages, let's focus on TypeScript. TypeScript's strong typing and runtime checks can catch issues early, sparing your users from cryptic error messages. Let's explore how to use this to make your API smarter and your users happier. Option 1: DIY Validation (AKA The "I've Got Trust Issues" Approac ## Update State Management with Pinia DevFeed: [Update State Management with Pinia]() Original publisher: [Read original article]() Author: Dusko Peric Published: 2024-03-21T14:43:21Z Content type: article Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Vue.js](), [Development](), [web applications](), [Code]() Tags: [article](), [debugging](), [developer-experience](), [development](), [pinia](), [state-management](), [typescript](), [vue-js](), [vuejs](), [web-applications]() ### AI overview This article explains Pinia as a state-management option for Vue.js applications. It describes Pinia's component-like store structure, direct state updates within actions instead of mutations, modular stores, Option and Setup Stores, TypeScript support, Vue Devtools support, and its lightweight design. ### Source excerpt In the development and maintenance of web applications, one of the crucial factors is the proper choice of state management. When it comes to Vue.js, we have two players in the game, where in my opinion, we have a clear winner. In this article, I will go through the functionalities brought by Pinia, which represent a step forward in this field. Intuitive API One of the problems in working with state is that it can very easily become confusing and complex. With its component-like structure, Pinia allows for easier understanding of how the store functions and interacts with your application. Let's look at an example to compare a Vue component with a Pinia store. Syntax similarity between Vue component and Pinia store This familiar syntax makes it a user-friendly and efficient solution for managing state. Excluding Mutations One of the key differences between Pinia and Vuex lies in the absence of mutations. In Vuex, the distinction between actions and mutations can become less clear-cut, particularly for complex stores. This redundancy can lead to repetitive code, adding unnecessary complexity to state management. Pinia takes a more direct approach. You can simply modify the state directly within actions. Let's see a code example to illustrate this concept: Vuex Store import { createStore } from 'vuex'; export default createStore({ state: { count: 0, }, mutations: { increment(state) { state.count++; // Update state through mutation }, }, actions: { increment({ commit }) { commit('increment'); // Dispatch mutation to update state }, }, }); Pinia Store import { defineStore } from 'pinia'; export const useCounterStore = defineStore('counter', { state: () => ({ count: 0, }), actions: { increment() { this.count++; // Directly update state within action }, }, }); In essence, Pinia removes an unnecessary layer of complexity by allowing direct state updates within actions. Modular stores design Pinia allow you to create multiple stores for different parts of your application, ## Automating Multi-Account Permission Management with AWS IAM Identity Center (previously AWS SSO) DevFeed: [Automating Multi-Account Permission Management with AWS IAM Identity Center (previously AWS SSO)]() Original publisher: [Read original article]() Author: Niko Jernejsek Published: 2022-12-22T10:32:09Z Content type: article Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [AWS IAM Identity Center](), [AWS Organizations](), [Single sign-on (SSO)](), [Authorization](), [IAM](), [CI/CD]() Tags: [aws](), [aws-eventbridge](), [aws-iam](), [aws-iam-identity-center](), [aws-organizations](), [cicd](), [cloudformation](), [iam-identity-center](), [least-privilege](), [saml](), [security](), [sso]() ### AI overview This article describes Homegate's multi-account AWS strategy and its use of AWS IAM Identity Center, formerly AWS SSO, to centrally manage permissions for engineers across AWS accounts. It explains the use of permission matrices, least-privilege access, AWS Organizations, external identity providers through SAML 2.0, and SCIM. ### Source excerpt Background Homegate was founded in 2001 and is now the leading property marketplace in Switzerland. Few years ago we decided to re-architect our monolithic real estate platform towards micro services on top of AWS cloud. At the moment, Homegate workloads are running almost exclusively on server-less compute model with teams organised around micro services. We are utilising so called multi-account strategy where we structure our AWS accounts around individual micro services further breaking them down into different accounts according to software lifecycle, and organising them into the AWS Organizational Units. We've structured our AWS Organizations Units & AWS accounts according to the recommendations provided by AWS (https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html#basic-organization-with-cicd-as-a-separate-function). Apart from having product workload accounts we also have accounts which are necessary to operate security, governance and platform related workloads. Access to accounts is governed by a permission matrix which is based on least privilege principles. The permission matrix classifies who (internally defined personas, e.g.: engineers/managers/security officers, etc) has what type of access (e.g. read-only or admin), and to what category of AWS accounts (e.g. production workloads, shared infra accounts, etc). Group of accounts in our Permission Matrix are at the same time AWS Organisational Units that we implement. As we have to manage permissions for hundreds of engineers to about hundred of AWS accounts accordingly, this way of grouping makes it easier for us to manage it at scale. IAM Identity Center PrimerIAM Identity Center Intro Note that I will be using AWS IAM Identity Center and AWS SSO interchangeably as even some services (such as CloudFormation) are still using the previous name AWS SSO. AWS IAM Identity Center is a single sign-on (SSO) service that allows AWS users to centrally manage acces ## Micro Service Events (AWS EventBridge vs. SNS) DevFeed: [Micro Service Events (AWS EventBridge vs. SNS)]() Original publisher: [Read original article]() Author: Kristian Müller Published: 2022-09-16T12:06:51Z Content type: comparison Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [event driven](), [Messaging](), [Amazon Web Services](), [Amazon Simple Queue Service (SQS)](), [Publish-subscribe pattern](), [Architecture & Design](), [AWS Lambda](), [Amazon API Gateway](), [DynamoDB](), [Amazon S3](), [TypeScript]() Tags: [api](), [api-gateway](), [architecture](), [aws](), [aws-eventbridge](), [aws-sns](), [data](), [data-processing](), [database](), [dynamodb](), [event](), [event-driven](), [eventbridge](), [eventbus](), [events](), [gateway](), [lambda](), [messaging](), [microservice-architecture](), [s3](), [sns](), [sqs](), [typescript]() ### AI overview This article examines Homegate's event-driven microservice architecture on AWS and compares Amazon SNS with EventBridge as messaging infrastructure. It describes how services use SNS, SQS, Lambda, API Gateway, DynamoDB, and S3, and explains that EventBridge has a different focus, so replacing SNS is not necessarily the right question. ### Source excerpt During the last few years, we've been busy rebuilding the Homegate platform in an event driven, micro service architecture based on AWS. One of the most important buildings blocks, or shall we rather say the mortar that connects the building blocks, is the way our services send events to each other. While Amazon offers its notification service SNS since more than 12 years; in 2019 it started a newcomer in the messaging bus field by introducing EventBridge. This was very interesting to us as we're using SNS a lot. Bus on a Bridge (Photo by "Blue Elf" on Wikimedia Commons) As EventBridge was introduced and gained traction we asked ourselves what advantaged we would gain by switching our SNS based service glue to EventBridge. Maybe this turned out to be the wrong question for us. Let's look at our system to see why. Micro Services Connected by SNS Homegate is connecting dozens of services via SNS right now. Those services range from single purpose Lambda functions written in TypeScript to database heavy services using Aurora or DynamoDB and Step Functions sending events to other services. Some of the services are also interfacing external APIs such as Salesforce or SendGrid. Here our Lambda functions can call APIs when needed. On the other hand, we have web services to be called as APIs by other systems and end users. This is mostly achieved via API Gateway. A typical service connects to the system by subscribing to events needed to fulfill its purpose. Those inbound SNS events are then ingested via SQS allowing for orderly data processing and DLQs to handle errors. Outgoing results are pushed back to the system in form of events to a SNS topics. As Marko Savic has pointed out, we're also utilizing S3 to store and replay those events if needed. Basic AWS Lambda function connected via SNS If we would replace the SNS topic by streams on the EventBridge we would initially gain the same functionality by utilizing SQS as well. However, EventBridge has a different focus. Let ## Configure renovate bot for npm at Homegate DevFeed: [Configure renovate bot for npm at Homegate]() Original publisher: [Read original article]() Author: Khanh Nguyen Published: 2022-05-23T12:29:19Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [renovate](), [npm](), [npm packages](), [configuration](), [GitLab](), [Automation](), [Development]() Tags: [automatic-deployment](), [automation](), [configuration](), [dependencies](), [github](), [gitlab](), [nodejs](), [npm](), [npm-packages](), [pipeline](), [pipelines](), [project](), [renovate](), [renovate-bot](), [review](), [security](), [upgrade](), [vulnerabilities]() ### AI overview This article explains how Homegate configured Renovate Bot to automate npm dependency updates across more than 200 repositories. It describes scheduled merge requests, concurrency limits, smart bundling, automatic merging for minor and development dependencies, review requirements for major upgrades, custom npm hosts, and team responsibilities for handling failures and breaking changes. ### Source excerpt Renovate bot is an automated dependency upgrade for npm packages. It supports many services such as gitlab & github. Homegate repositories structure At Homegate, we have over 200 repositories in micro-services architecture. Keeping services up to date is quite a big overhead. However, the benefits are obvious: Bugfixes New features Security issues / less vulnerabilities Evaluation session result from our engineering teamThe standard configuration We try to make process as automated and standardised as possible. The configuration will automatically create MRs for minor and major upgrade in our gitlab repos and auto-merge them. It is necessary to allow merge without approval in these repositories. Below you'll see our standard configuration with the following features: Schedule MR creations every hour on weekdays Limits apply (concurrent MRs / Rate of creation) Smart bundling can be configured, such as having all linters together or all of our shared frontend library related MRs together Auto-merge for minor and dev-dependencies Separation of major upgrade (requiring review) vs. minor upgrade (auto-merged) Configuration for custom npm host Each project has renovate.json that extends the standard homegate.json with custom config if necessary { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:base", ":prHourlyLimitNone", ":automergeLinters", ":automergeTesters", ":automergeTypes", ":automergeMinor", "group:definitelyTyped", "group:postcss", "group:linters", ":rebaseStalePrs", ":maintainLockFilesMonthly" ], "prConcurrentLimit": 2, "schedule": [ "after 6am and before 5pm every weekday" ], "ignoreDeps": ["node-sass", "stylelint", "stylelint-scss", "stylelint-config-standard", "stylelint-config-css-modules"], "packageRules": [ { "matchPackagePatterns": ["vue", "vue-router", "vuex"], "matchUpdateTypes": ["major"], "enabled": false }, { "matchPackagePatterns": ["^@aws-cdk", "aws-cdk"], "matchUpdateTypes": ["major"], "enabled": false }, { "d ## Coroutines on Android DevFeed: [Coroutines on Android]() Original publisher: [Read original article]() Author: Stevan Milovanovic Published: 2022-05-20T12:36:23Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Coroutines](), [Android](), [async](), [Concurrent Programming](), [context]() Tags: [android](), [android-app-development](), [android-apps](), [article](), [async](), [asynchronous](), [cancellation](), [coroutine](), [coroutine-testing](), [coroutines](), [dispatcher](), [kotlin-coroutines](), [lifecycle](), [programming](), [thread](), [threads]() ### AI overview This tutorial explains why Kotlin coroutines can be preferable to threads for asynchronous and background processing on Android. It introduces coroutine scopes, contexts, suspending functions, jobs, and dispatchers, and describes using coroutines for networking and background processing. ### Source excerpt Coroutines on Android In this article I'll try to explain why coroutines are useful and why would you want to use them in your project. After we go through the most important concepts of coroutines, I'll show you how I used coroutines to implement networking and background processing in the example project. First of all, you might ask yourself, why we want to use coroutines over threads? Main problem with threads is that they are resource intensive, meaning it takes a lot of resources to start a thread, stop a thread. Meanwhile, coroutines are lightweight threads, since they use thread pools. Another benefit of coroutines is that they greatly simplify asynchronous code. Callbacks and synchronisation are very easy to use. In fact, they make parallel programming look very much like sequential programming. Coroutines can be paused and resumed at any time, on a number of threads. And lastly, since coroutines are based on a few fairly easy to grasp concepts, their syntax is simple and easy to use. Here are the main concepts we need to explain about coroutines: Scope Coroutine scope, as its name says, defines a scope for new coroutines. Every coroutine builder (like launch and async) is an extension on CoroutineScope and inherits its coroutineContext to automatically propagate all its elements and cancellation. Context Coroutine context represents the context of its scope. Context is encapsulated by the scope and used for implementation of coroutine builders that are extensions on the scope. Scope provides a context in which the coroutine runs (state of the coroutine which provides variables, functionality of the coroutine etc.). Suspending functions Suspending functions are functions that can be run in a coroutine. They make callbacks seamless. They can be run in a coroutine (can be suspended) and that is why they can provide functionalities which have to be run in parallel. Job Job is a handle on that coroutine (on the piece of code which runs in the background). A laun ## Replaying events using AWS S3 DevFeed: [Replaying events using AWS S3]() Original publisher: [Read original article]() Author: Marko Savic Published: 2022-04-08T08:40:24Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Amazon S3](), [event driven](), [Microservices](), [Amazon Web Services](), [AWS CloudFormation](), [Serverless]() Tags: [aws](), [aws-lambda](), [aws-s3](), [cloudformation](), [debugging](), [event-driven](), [event-sourcing](), [lambda](), [microservices](), [s3](), [serverless](), [sns](), [software-architecture](), [versioning]() ### AI overview This tutorial describes replaying failed events in serverless, event-driven microservices by storing AWS Step Functions events in versioned Amazon S3 objects. It also outlines using a dead-letter queue and Lambda to retrieve the latest event and trigger the workflow again. ### Source excerpt In the world of event-driven microservices one of the important tasks is to have a mechanism to recover from failed events, as well as to have possibility to replay certain events. We at Homegate deal with serverless microservices. If, at any of these services, we encounter a failure during processing of an resource, we might need to recreate the last event or series of events for given resource. Usecase The central part of ingestion process is AWS StepFunctions that lives in a, so called, importer service. It is responsible for various enrichments and conditional actions on resource. The last step of the step function is sending an event to the AWS SNS which is consumed by many downstream services as you can see in the following diagram. Step functions as central part of ingestion process Here, many open questions can be identified: How to deal with failure within AWS StepFunctions? How to recreate SNS event if needed for downstream system? Would it be possible to replay the whole step function? Solution Possible answer to these questions would be to store events that goes through AWS StepFunctions into some kind of event storage, in Homegate case, we chose AWS S3. In order to support the whole history of events for given resource, S3 bucket versioning is used. This is quite handy for replaying series of events or even for debugging purposes. Here is a sample CloudFormation which enables that functionality: EventLogBucket: Type: 'AWS::S3::Bucket' Properties: BucketName: 'sample-unnique-bucket-name' AccessControl: Private PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: service Value: sample-service - Key: env Value: !FindInMap [ Stages, !Ref Stage , Env ] VersioningConfiguration: Status: Enabled That way we can replay the whole step functions flow using last logged event for given resource. That functionality could be available from different places, like DLQ or via api end ## AWS FIFO Queues with Message Groups for Atomic Processing at Scale DevFeed: [AWS FIFO Queues with Message Groups for Atomic Processing at Scale]() Original publisher: [Read original article]() Author: Nick De Cooman Published: 2022-03-03T09:55:58Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Amazon Simple Queue Service (SQS)](), [Amazon Web Services](), [Serverless](), [event driven](), [Scalability](), [Publish-subscribe pattern]() Tags: [architecture](), [aws](), [decoupling](), [distributed](), [event](), [event-driven](), [events](), [fifo](), [serverless](), [sns](), [sqs]() ### AI overview A tutorial on using AWS FIFO queues and message groups to process events for multiple objects in parallel while ensuring that only one instance processes events for the same object at a time. It presents a serverless architecture using SNS, SQS, and Lambda for atomic listing ingestion. ### Source excerpt How to process multiple objects in parallel with the guarantee that for each unique object, only a single instance is processed simultaneously In a distributed, event-driven architecture, many challenges arise when processing large sets of data. One of them is the need for scalability when handling event streams with a substantial throughput. The challenge becomes even more complicated when processing these events involves atomic operations. In this case, we cannot simply process multiple events in parallel. As an example, let's say that we are building a service that ingests listings into our platform. The ingestion process involves several steps and requires multiple API operations. As a result, the whole ingestion can take up to several seconds per listing to complete. Now, here is where it gets tricky: a constraint of our service is that, while we are processing a listing, we cannot process other events for the same listing. The ingestion should be considered an atomic operation, and hence, only a single execution per listing can be performed simultaneously. At Homegate, we run most of our infrastructure on AWS in a serverless fashion. At the core of this, Lambda functions execute application logic. A common pattern is to use SNS topics to fan-out messages, and SQS for acting as a decoupling buffer between an SNS topic and some Lambda function. For our ingester service, a logical architecture could look like this: Listing events are published to a dedicated SNS topic. An SQS queue subscribes to this topic and consumes the events. Here, the events are buffered until a Lambda instance removes them from the queue and processes the corresponding listing. Under normal circumstances -- in which the processing would not involve an atomic operation -- this architecture would be a good fit. It would scale automatically relative to the number of Lambda instances that consume events from the queue, without much additional configuration. However, in the case where we cannot p