# klarna Published articles for klarna. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 ## 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