# Klarna Engineering Disrupting the financial sector starts and ends with products that work, are easy to use and stable day after day. The Engineering competence is pivotal in creating, maintaining and developing the Klarna experience. - 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. ## Beyond Prompting: How Algorithmic Evolution Doubled our Training Speed DevFeed: [Beyond Prompting: How Algorithmic Evolution Doubled our Training Speed]() Original publisher: [Read original article]() Author: Rex Lin Published: 2026-03-30T12:47:12Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Artificial Intelligence](), [Optimization](), [Code](), [Google](), [Transformer](), [systems]() Tags: [ai](), [artificial-intelligence](), [code](), [engineering](), [evolution](), [google](), [machine-learning](), [optimization](), [software-engineering](), [speed](), [training]() ### AI overview Klarna describes using Google's AlphaEvolve to explore code optimizations for a large transformer-model training pipeline. Across nearly 6,000 candidate programs over three weeks, the system reportedly doubled training speed and produced a better model. Engineers defined the sandbox, metrics, constraints, hints, and error handling while AlphaEvolve generated, tested, and scored candidates. ### Source excerpt By Rex Lin and Valeria Verzi (Klarna Engineering), with Anant Nawalgaria (Google) We knew our training pipeline could be faster -- significantly faster. At Klarna, one of our largest models (a transformer trained on vast streams of payment events and shared like infrastructure across many internal systems) is on a tight training loop. Speed is money at our scale. The opportunity for improvement was not in the hyperparameters, but in the plumbing: the way numbers moved between processors, the way memory was allocated, the way the model performed its most basic mathematical operations. The challenge was scale. An engineer might try five or ten structural rewrites. A particularly ambitious one, armed with an AI coding assistant, might push to a hundred. But the full search space, the universe of possible combinations of precision formats, data pipelines, attention mechanisms, and gradient strategies, numbered in the thousands. We partnered with Google to apply a different kind of tool. Instead of trying to prompt our way to a solution, we handed the problem to AlphaEvolve, which treats code optimization the way evolution treats organisms: generate candidates, test them, keep the fittest, repeat. Over three weeks and nearly 6,000 candidate programs, it doubled our training speed and, unexpectedly, produced a better model in the process. The Machine That Writes Machines AlphaEvolve is not a chatbot for code. You don't interact with it through prompts. Instead, you build a sandbox around it. The engineer's job is to define what can change in the code and what cannot (passing only structural code snippets to the system, never customer data) to specify the metric that matters, and to set the constraints that must never be violated. You write hints in the form of code comments. You craft error messages that help the system learn when it fails. Then you step back. The system takes over from there. It generates a candidate program, runs it, measures the result, scores it. The b ## How Klarna Built Cloud Inventory for AWS Configuration Management DevFeed: [How Klarna Built Cloud Inventory for AWS Configuration Management]() Original publisher: [Read original article]() Author: Maxim Savin Published: 2025-06-06T06:38:06Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [configuration-management](), [cloud-infrastructure](), [Amazon Web Services](), [configuration](), [Cloud](), [Security](), [digital]() Tags: [automated](), [aws](), [change-management](), [cloud](), [cloud-infrastructure](), [cloud-inventory-software](), [configuration-management](), [engineering-management](), [lead-time](), [load-balancer](), [logs](), [rds](), [security](), [snapshots](), [technical-change]() ### AI overview Klarna describes Cloud Inventory, an ecosystem of services for collecting, normalizing, mapping, and serving information about ICT assets across its cloud infrastructure. The article explains how it supports configuration management through automated controls and reports faster control rollout and large-scale infrastructure optimization work. ### Source excerpt A long time ago, as a punishment for his crimes, Hades, the king of the underworld, made Sisyphus roll a huge enchanted boulder endlessly up a steep hill. Since then, many tech companies have learned to do that at scale by the hardships of cloud configuration management. Consider an Engineer who wants to ensure that the data that moves through their system is encrypted along the way. This is a noble goal, and to achieve it they must identify every classic load balancer in their AWS environment to replace it with an application load balancer that enforces encryption in transit. Now imagine doing that at the scale of a company like Klarna, where teams collectively own more than a thousand AWS accounts? Add to this a multitude of other configuration challenges -- databases that have not been deployed in a multi-availability zone set-up, missing Cloudwatch logs, expired digital certificates, systems running on unsupported framework versions -- the list is endless. Identifying and rectifying violating cloud assets often feels like an endless game of whack-a-mole played blindfolded. This is the steep price tech companies pay to operate their systems securely and confidently, day by day. Klarna Engineering Platform (KEP) has been on a mission to facilitate configuration management for Klarna Engineers. After a few iterations we have built an ecosystem of Klarna services designed to collect, normalize, map, and serve data on ICT assets within Klarna's cloud infrastructure. We call this system Cloud Inventory. Over the last few months Klarna has: Rolled out over 100 automated controls enhancing every aspect of our configuration management (security, governance, and operational excellence), each control aimed to help system owners to identify and fix violations quickly. Reduced the lead time of rolling out a control from several weeks to a matter of minutes And as a result, successfully completed several large-scale cloud infrastructure optimization projects, such as a company- ## Learnings from a Klarna Engineer on feature development DevFeed: [Learnings from a Klarna Engineer on feature development]() Original publisher: [Read original article]() Author: Julien Avezou Published: 2025-04-14T09:05:53Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Development](), [Usability](), [Security](), [Scalability](), [Slack](), [Testing](), [Architecture & Design]() Tags: [bug](), [collaboration](), [communication](), [development](), [documentation](), [engineering](), [fintech](), [klarna](), [learning-to-code](), [scalability](), [security](), [slack](), [software-development](), [software-engineer](), [technical](), [testing]() ### AI overview A Klarna engineer shares lessons from developing a feature that helps users recover access to Klarna Card and Klarna balance accounts. The article emphasizes early and ongoing documentation, open communication through dedicated Slack channels, and collaborative Bug Bashes to support feature development. ### Source excerpt In the world of FinTech, where regulations and innovation collide, my team at Klarna implemented new ways for users to recover access to their Klarna Card and Klarna balance accounts on their device. This posed a series of challenges with a whole range of aspects to consider from product, usability, security, scalability and regulatory. With the feature now released, I would like to share key learnings from working on this complex feature. Documentation is Key Starting to document early on in the project is crucial. We generated documents at all stages of our project in order to gather feedback at a technical, product and design level. This helped in aligning with teams, enabling smooth collaboration, and setting a solid foundation for feature development and delivery. These documents allow close and continuous collaboration between stakeholders from both product, technical and design perspectives from the early stages of feature discovery to the start of implementation. However documentation doesn't stop there, once the implementation is done, it is equally as important to capture in writing your feature from both product and technical aspects, supported by architectural diagrams and swimlanes, so that stakeholders within the company have a clear reference when interacting with the feature in the future. Always communicate Establishing open communication channels, such as dedicated Slack channels for internal stakeholders, and providing regular updates in order to foster collaboration. Promptly raising blockers and organizing group discussions with colleagues from various competences ensures transparency and helps in addressing challenges effectively. Having an open channel to discuss and update on progress also helped streamline our communication and avoid unnecessary meetings. Having an open channel also serves as an accountability mechanism and a great way to keep track of the conversations and topics over time. The dedicated channel also provides an easy way to ## Choosing the Right Granularity for Microservices: Klarna's Payments Architecture Journey DevFeed: [Choosing the Right Granularity for Microservices: Klarna's Payments Architecture Journey]() Original publisher: [Read original article]() Author: Raya Rizk Published: 2025-03-24T07:22:27Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Microservices](), [Architecture & Design](), [Development](), [Software Engineering](), [Scalability]() Tags: [architecture](), [challenges](), [distributed](), [klarna](), [led](), [microservices](), [modular-monolith](), [monolith](), [organizational-structure](), [scalability](), [software-architecture]() ### AI overview This article describes Klarna's transition from a monolithic architecture to payment-specific microservices and examines the trade-offs of service granularity. It reports that independently managed services improved team autonomy and development speed, while duplicated shared functionality created a complex distributed monolith. ### Source excerpt Our journey towards striking the right balance The debate between monolithic and microservices architectures is a hot topic in software development. While monolithic systems are known for their simplicity and tightly integrated structure, they face challenges with scaling and flexibility. In contrast, microservices offer greater scalability and autonomy in development, but carry complexity in inter-service interactions. In this article, I'll share our experience in navigating between these two paradigms while working on a recent project at Klarna, exploring different architectural decisions while addressing a fundamental question: what is the optimal granularity for a microservice? From monolith to microservices: the company is growing 🚀 A monolithic architecture is often the natural starting point for businesses, serving well initially but revealing its limitations as organizations scale. Klarna was no exception. Like many in the IT industry, the company embraced the microservices paradigm alongside its rapid growth a few years ago. In the payments domain, we are focused on offering customers various payment options, allowing them to choose between paying directly, later, over time, or through other tailored methods. This demand for diverse options led each payment method to evolve into a distinct microservice, managed by dedicated teams. Each payment service acts as a key orchestrator in the purchase flow, coordinating with other services to guide customers through the required steps until order completion. This adoption of microservices naturally aligned with the company's organizational structure, offering team autonomy and the ability to scale services independently. Each service was self-contained, with its own database and code residing in a separate repository. By decoupling payment options into distinct services, we gained greater flexibility and enabled faster development cycles, as teams could focus on their respective components. Landing the distributed ## How Klarna Migrated the KRED System from Mnesia to Postgres with Zero Downtime DevFeed: [How Klarna Migrated the KRED System from Mnesia to Postgres with Zero Downtime]() Original publisher: [Read original article]() Author: Onno Vos Dev Published: 2025-02-26T09:04:27Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Databases](), [Erlang](), [Replication](), [sharding](), [Transactions](), [systems]() Tags: [cluster](), [databases](), [erlang](), [klarna](), [memory](), [postgresql](), [production](), [replication](), [scaling](), [sharding](), [software-development](), [software-engineering](), [transactions]() ### AI overview This article describes Klarna's migration of KRED, an Erlang servicing system, from Mnesia to Postgres with zero downtime. It explains the original replicated seven-node architecture, the system's scaling challenges, and a plan involving sharding across multiple clusters. ### Source excerpt How we migrated from Mnesia to Postgres with zero downtime Back in December 2004, an Erlang application was born called KRED (referring to the freshly-started company called Kreditor, now known as Klarna). KRED is one of the "servicing systems" at Klarna and keeps track of consumer debt (among other things). It was powered by Mnesia and consisted of a cluster of 7 nodes, each holding a full copy of the database on disk. The data was replicated using a custom replication mechanism built in-house by Klarna. One node was elected as the leader and its database was considered the source of truth in the system. All database transactions were executed on the leader and writes were replicated to the rest of the nodes, the so-called followers. The Mnesia database was around 15 TB and at its peak in 2018 around 1.3 TB was held in memory at all times. Considering that few suppliers were selling hardware with such specs, it's easy to claim the crown of one of the biggest Mnesia databases in terms of in-memory storage, that was running in production. The rest of the data was offloaded to disk using mnesia_eleveldb. KRED has been a stable workhorse at Klarna so why change a winning concept? Get ready, for a two part blog post where we'll first go through our journey of how we went about this and secondly, how we made Mnesia behave just like Postgres and implemented our version serializable isolation level on top of Postgres! How the journey started Three engineers, sat down in a bar in Stockholm, Sweden and asked this question: 'When Klarna truly takes off, will KRED survive? Assuming "no", and presented with a blanco check, how would we tackle this problem?' The answer quickly revolved around the issues of running Mnesia on an even larger cluster and with leveldb compaction hitting some hot tables during peak times. One can only imagine how that problem would just continue to get worse over time. Considering the three engineers had worked on KRED for a long time, scaling KRED wa ## Automating the Klarna Card Ownership Fees System using AWS Step Functions DevFeed: [Automating the Klarna Card Ownership Fees System using AWS Step Functions]() Original publisher: [Read original article]() Author: Michel Neumann Published: 2024-05-02T07:42:27Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [AWS Step Functions](), [AWS CloudFormation](), [Automation](), [jira]() Tags: [athena](), [automation](), [aws](), [aws-step-functions](), [cloudformation](), [databases](), [jira](), [klarna](), [maintenance](), [pull-requests](), [run](), [serverless](), [step-functions](), [workflow]() ### AI overview The article explains how Klarna automated its Klarna Card monthly fee-collection process with AWS Step Functions and CloudFormation. The automation replaced a manual, multi-day batch workflow with a scheduled process and reduced maintenance effort. ### Source excerpt This article outlines how my team and I applied automation using AWS Step Functions and CloudFormation on a system to charge the monthly fee for Klarna Cards, enabling us to transform a previously manual routine into a self-sufficient, scheduled workflow. The initiative significantly streamlined operations and reduced maintenance cost. Introduction In early 2023, Klarna introduced monthly fees for Klarna Cards in the US. In the Card & Banking domain, two teams, including myself as engineer, developed this system within a tight four-month deadline. Initially, the system required extensive manual operation, including a detailed checklist for engineers to follow to ensure successful executions. The teams launched, planning iterative improvements of that routine. Months passed by without any advancement in refining the operation process nor automating any part of it. To provide an overview of what needed to be done by the teams to run the batch jobs: Designating an engineer to lead the monthly process, coordinated using JIRA tickets Updating exemption lists and submitting pull requests to the code-base prior to initiating batch runs Ensuring data integrity by performing Athena queries across three different production databases within the AWS Console Manually initiating multiple batch jobs in a specified sequence with manual input of arguments in a live production setting Awaiting termination of the jobs and conducting a thorough review of the outcomes of the final batch jobs for each market Overall, this routine took around three business days per month and required two engineers to approve code changes and review the results of the batch runs. Considering new markets where fees may be rolled out towards, this workflow posed a significant challenge to maintaining high-quality standards and preventing potential incidents. Taking on The Challenge We recognized that continuing with our current process was unsustainable and bound to cause issues down the line. When the top ## Peak Season 2023 : How Klarna achieved consistent success DevFeed: [Peak Season 2023 : How Klarna achieved consistent success]() Original publisher: [Read original article]() Author: Anu Sasidharan Published: 2024-03-01T08:52:56Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Resilience](), [systems](), [Cloud]() Tags: [cloud](), [efficiency](), [resilience](), [systems]() ### AI overview Klarna describes how it prepared for and operated through the 2023 peak season. The company reports zero critical or major incidents, a 30% reduction in overall incidents compared with 2022, optimized cloud costs, and improved engineer efficiency. The article also explains the scale of seasonal traffic and the systems and teams involved. ### Source excerpt Peak Season 2023 : How Klarna achieved consistent successIntroduction This article summarizes how Klarna consistently achieved its Peak Season goals during 2023. In 2023, we aimed higher. We were committed to continual improvement, building on the progress made in 2022. Our primary focus was to deliver the best possible experiences to our customers. During the Black Friday sale, we broke our own records, a testament to our commitment and capability. 1. Klarna's systems showed resilience with zero critical or major incidents, and we saw a 30% reduction in overall incidents compared to 2022. 2. We optimized the management of resources, leading to optimal cloud costs. 3. We paid special attention to our engineer's experience, ensuring a smooth Peak Season preparation. This improved efficiency, and lessened the workload. The topics this article covers: Peak Season at Klarna Factors contributing to our success Approaches to Peak Season essentials Lessons learned Peak Season at Klarna The most important time of the year for Klarna is the 'Peak Season.' It starts with the busy week of Black Friday and ends with the sales at the end of the year. Peak Season gets busy because of Holidays and Festivals, Sales and Discounts, and seasonal necessities. During this time, e-commerce and fintech companies buzz with heightened activity, with Klarna being a significant player amidst them. Why is the Peak Season important for Klarna? Klarna's mission is to give shoppers around the world easy, safe, and 'smoooth' ways to pay. We handle an average of over 2 million purchases every day, serving over 150 million active shoppers at more than 450,000 sellers in 45 countries. On Black Friday, we handle more than 3 times the usual daily purchases. Big sales events, especially flash sales, mean our systems have to manage a lot of traffic. Flash Sales are quick discounts or promotions from stores that get buyers excited. This rush adds to the already busy season, and our systems have to quickly ## Evaluating Binary Classification Metrics on Imbalanced Datasets DevFeed: [Evaluating Binary Classification Metrics on Imbalanced Datasets]() Original publisher: [Read original article]() Author: Angel Igareta Published: 2023-11-09T09:22:53Z Content type: tutorial Language: en Sources: [Klarna Engineering]() Topics: [Data Science](), [Machine Learning & Artificial Intelligence](), [data]() Tags: [classification](), [data-science](), [datasets](), [evaluation](), [false-positives](), [imbalanced-data](), [machine-learning](), [model](), [predictions]() ### AI overview This tutorial examines GINI and ROC_AUC for evaluating binary classification models, explaining why their effectiveness can be compromised by imbalanced datasets and presenting the Precision-Recall curve as a potentially more robust alternative. ### Source excerpt Discover how the Precision-Recall curve can provide a more robust metric for binary classification in data science and machine learning. Imagine stepping into the complex world of binary classification problems. As a Senior Data Scientist at Klarna, this is my day-to-day reality. Binary classification is a cornerstone of data science, with applications touching everything from credit default predictions to medical diagnoses and spam detection. Yet, these problems come with their own unique set of challenges. Metrics such as the GINI coefficient and ROC_AUC often serve as our compass in this maze. They are widely trusted and used for evaluating models. But here's the catch: they might not always point us in the right direction. Can we rely on them blindly, or do we need to dig deeper? The path gets even more challenging when we encounter imbalanced datasets. In such cases, the effectiveness of our trusted metrics can be seriously compromised. In this post, I invite you to join me on a journey to explore these metrics in greater depth. We will question their effectiveness, understand their limitations, and reveal alternatives that could prove to be more reliable navigational tools in the world of binary classification problems. Understanding Model Predictions and Metrics To truly grasp the nuances of model evaluation, let's start by setting the stage with a real-world scenario that we often encounter at Klarna. Imagine we're tasked with predicting customer loan defaults. We have two categories to consider -- paid or default. However, in our scenario, the default rate is a mere 2%. This is a classic case of data imbalance, and it's exactly the kind of challenge we're up against. To evaluate our model's performance in this scenario, we need to understand its predictions. We break these down into four distinct outcomes, also known as the confusion matrix: True Positives (TP): These are the customers who our model correctly identifies as defaulters. False Positives (FP): T ## Building a ChatGPT Add-On for Google Workspace: Integration Challenges and Lessons Learned DevFeed: [Building a ChatGPT Add-On for Google Workspace: Integration Challenges and Lessons Learned]() Original publisher: [Read original article]() Author: Mikael Wulfcrona Published: 2023-10-16T09:50:38Z Content type: opinion Language: en Sources: [Klarna Engineering]() Topics: [ChatGPT](), [Google Apps Script](), [Google](), [API](), [JavaScript](), [Language models]() Tags: [add-ons](), [api](), [challenges](), [chatgpt](), [google-workspace](), [javascript](), [langchain](), [limit](), [productivity](), [work]() ### AI overview The author describes building a Google Workspace add-on that integrates ChatGPT for textual interactions with data in Google Sheets. The main challenges included extracting text across Google Workspace, ChatGPT's token limit, the 60-second execution limit for Google add-ons, and handling raw spreadsheet data. ### Source excerpt Overcoming the Hurdle of Unformatted Input: What I Learned From Building a ChatGPT Add-On for Google Workspace While ChatGPT is an incredibly powerful language model, it still struggles with unformatted input. As a tech nerd and passionate data scientist, I recently embarked on a journey to create an add-on for Google Workspace that could seamlessly interact with data stored in Sheets. Follow along as I share some of the main challenges, learnings, and solutions that eventually allowed me to integrate ChatGPT into Google's productivity tools for textual interactions. Unleashing the Potential of ChatGPT I was one of many people who was very impressed with the early versions of ChatGPT, released at the end of last year. Its capability to generate human-like responses fascinated me. However, I struggled to integrate it into my daily work. Having to switch tabs and copy-pasting text from different documents kept me away from really adopting this new tool. Determined to overcome this hurdle, I dove into the world of Google Workspace add-ons. You know where the work with text actually happens. Armed with enthusiasm and basic JavaScript knowledge, I got into building my first add-on. Having never built an add-on before, I forked Google's own example repo and started working. Working with the Google API As I delved into the project, I realized integrating ChatGPT via API calls was relatively straightforward. OpenAI provided excellent documentation, and Google Apps Script offered built-in features to make API calls. The main challenges, actually, laid on the Google side. Extracting text from different apps within the Google Workspace ecosystem initially baffled me. I spent hours unraveling the intricacies of the Google API, determined to find a way to seamlessly access and manipulate data. Overcoming GPT's Limitations with Raw Data in Google Sheets As I progressed, I encountered more roadblocks. Firstly, the infamous token limit. Some document were quite long and simply not ## Introducing native E2E testing: Learnings from the Senior Engineering Program for Women DevFeed: [Introducing native E2E testing: Learnings from the Senior Engineering Program for Women]() Original publisher: [Read original article]() Author: Joana Melo Published: 2023-09-08T12:35:44Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Testing](), [App](), [Development]() Tags: [appium](), [automated](), [diversity](), [e2e-testing](), [engineering](), [gender](), [gender-equality](), [klarna](), [learnings](), [professional-development](), [regression](), [testing](), [typescript]() ### AI overview The author describes introducing native end-to-end testing in mini versions of the Klarna app to enable automated feature regression tests in development pipelines. The article also reflects on the Senior Engineering Program for Women, including its focus on professional growth, coaching, collaboration, technology, influence, and diversity. ### Source excerpt I made company-wide impact by successfully delivering the introduction of native end-to-end (E2E) testing in mini versions of the Klarna app. The goal was to have automated feature regression tests in our pipelines. I developed this as part of a program for senior engineering women, and today, I want to share the insights and learnings I gained from this experience. Creating fair and equal opportunities for women How do we offer women equal and fair opportunities in an industry dominated by men? Well, there are many ways to work on this topic. One that piqued my curiosity was Klarna's Senior Engineering Program for Women (SEPW). As you might wonder as well, my initial thoughts on it as with any other initiatives like this came with a lot of reservations: Is this fair? Is this the best way for me to ensure that I'm being fairly evaluated? Will it look like I am being brought to a speedlane towards an easy promotion if I happen to get one because I'm a woman? Are we going to get treated like tokens? Is this all just a marketing strategy to promote? Am I being part of and legitimizing something that has no real content and value for my career or other women? What will everyone think? When we are faced to join initiatives related to gender gap improvements, we might fall into the trap of having all the perfect and right answers before we take risks, or we can accept that there will never be the perfectly carved, impactful and life-changing solution at our doorstep. We can only experiment and learn from the results to make better decisions as we help evolving into a hopefully more gender-fair world. As a woman in engineering, I understand the issues, but I don't claim to have all the answers. And that's ok. The program The SEPW is a way for Klarna to acknowledge and accelerate the professional development of promising engineers and promote diversity within engineering. The 6 month program is designed with the individual's growth as the main focus, and based on four theme