# Wise Engineering - Medium Posts from the @Wise Engineering Team - 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. ## Data Inventory DevFeed: [Data Inventory]() Original publisher: [Read original article]() Author: Ritesh Modi Published: 2025-02-19T14:24:14Z Content type: tutorial Language: en Sources: [Wise Engineering - Medium]() Topics: [data-governance](), [data-architecture](), [Security & Privacy](), [Databases](), [Provisioning](), [Terraform]() Tags: [backend](), [data](), [data-governance](), [databases](), [frontend](), [governance](), [least-privilege](), [network-segmentation](), [platform](), [provisioning](), [security](), [security-privacy](), [terraform]() ### AI overview Wise's Data Governance team describes Data Inventory, a catalog of data assets that records their locations and security or privacy controls. The article explains the system's constraints, design outcomes, and process for discovering operational databases and their metadata. ### Source excerpt The Data Governance team, part of Data Platform, develops and operates platform products through which autonomous teams can govern their data. The team's vision is to democratise data in a secure and compliant manner. Data Inventory was the team's first product. What is Data Inventory? A data inventory is an extensive catalog of the Wise's data assets. It helps us understand where the data is located and what kind of security / privacy controls are in place. This is also a requirement for ISO 27001:2022. What are the constraints? Any system has to work well with our controls and way-of-working. This led to following constraints: It shall be built in a way that satisfies our security controls such as network segmentation, least privilege access, secure secret management, etc. It shall be easy to integrate with other in-house platforms to provide cohesive experience. It shall be built to connect with heterogeneous and fragmented infrastructure. Many data systems are built through off-the-shelf or managed service offering but others are built & operated in-house. The system shall be integrated by default with technology provided by Data Platform. On another hand, it shall be extensible enough to integrate with data systems not maintained by Data Platform. How did we build our inventory? At high level, we split this into 4 main outcomes: 1. Register assets at correct granularity. 2. Identify the correct owner and make them accountable for the life cycle. 3. Extract the schema of the data asset. 4. Classify the asset with correct sensitivity. This is how design looks at high level: To achieve the above design and outcome, we follow the following steps: Step 0: Discover data systems network metadata Scanners need to be aware of the network metadata before doing scanning. For example: - What is the host or connection string? - What is the technology of the data system? - What is the name of the data system? Let us take an example of how we solve it in our operational datab ## Wise Tech Stack (2025 update) DevFeed: [Wise Tech Stack (2025 update)]() Original publisher: [Read original article]() Author: Milon James Published: 2025-02-12T13:34:08Z Content type: article Language: en Sources: [Wise Engineering - Medium]() Topics: [Development](), [Mobile](), [Web](), [Tuist](), [Storybook](), [Testing](), [build performance]() Tags: [build-times](), [caching](), [data](), [engineering](), [mobile](), [next-js](), [platform](), [storybook](), [swift](), [swift-package-manager](), [tech](), [tech-stack](), [testing](), [tuist](), [update](), [web](), [xcode](), [xcodegen]() ### AI overview Wise's 2025 technology update describes its web, iOS, and Android engineering stack, including Next.js-based web applications, Storybook visual testing, migration from Xcodegen to Tuist, adoption of Swift Package Manager, and Android development across a large Gradle repository. ### Source excerpt Wise Engineering As of the financial year 2025, Wise supports 15.6 million active customers, moving approximately GBP 36 billion across borders each quarter. Approximately 65% of our transfers arrive instantly, and our Wise Platform facilitates payments for banks, financial institutions and enterprises globally. This success is driven by our technology-first approach, robust architecture, and dedicated engineering teams. Photo by Randy Fath on UnsplashHow we work at Wise Wise has more than 850 engineers working across key global locations, organised into independent squads and tribes. These teams are empowered to innovate and make decisions independently, fostering transparency, trust, and collaboration. This article follows our Tech Stack 2022 to cover the most recent improvements in Wise's tech stack that enable us to achieve our mission of money without borders -- instant, convenient, transparent and eventually free. Moving money with WiseOur web and mobile applications Our web applications are built using CRAB (a Wise-specific abstraction on top of the popular Next.js framework) and comprises of 40 distinct apps, each handling specific product functions making deployments safer and more manageable. One of the biggest changes has been in our testing methodology. We've adopted Storybook for visualising individual React components during development. Storybook pairs really well with Chromatic which captures snapshots after each change and can highlight the visual differences in the component. These snapshots are very effective for catching visual regressions during code changes which helps us prevent bugs from reaching our customers. Wise mobile app: faster, smarter, and more efficient Our iOS engineers have upgraded our infrastructure by migrating 250+ Xcode modules from Xcodegen to Tuist and switching from Cocoapods to Swift Package Manager (SPM), unlocking improvements in caching for builds. The team also improved flexibility, reducing zero-change build times from 2 ## How did we build 3D animations in mobile apps? DevFeed: [How did we build 3D animations in mobile apps?]() Original publisher: [Read original article]() Author: Yağız Gürgül Published: 2025-01-29T16:59:35Z Content type: tutorial Language: en Sources: [Wise Engineering - Medium]() Topics: [Three.js](), [Mobile](), [WebGL](), [HTML]() Tags: [3d](), [animation](), [gltf](), [html](), [mobile](), [optimisation](), [optimization](), [three-js](), [webgl]() ### AI overview Wise describes how it brought its 3D illustrations to life as interactive real-time animations in mobile apps. The team chose three.js scenes rendered in local HTML files inside mobile app web views, using WebGL for both iOS and Android, and then optimized large glTF assets for mobile delivery. ### Source excerpt In March 2023, Wise launched its new brand -- as part of it, we introduced a collection of bold new 3D illustrations. While visually stunning, our brand team had bigger ambitions to bring them to life and elevate Wise further. This took us on a journey to understand the technical landscape and challenges around creating a seamless multi-platform solution for interactive 3D animations. interactive 3D intro on Wise iOS appThe new illustration set in Wise Our new illustration set took inspiration from icons, allowing us to communicate with a global audience. They're unique, bold and dynamic, even when still. They give us opportunities to share moments of delight with our customers and help our brand stand out from billboard to button. check out https://wise.design/ for more! What sets illustrations at Wise apart is that they're not static. Each one is paired with a crafted 3D model, featuring detailed UV maps, precise shading, and carefully designed lighting. This raises an exciting question: What if we rendered these illustrations dynamically in real time, making them interactive on mobile apps? Native or web view? To render illustrations in real time, we explored several technical solutions: Native Filament three.js We opted to create 3D scenes using three.js, one of the most popular open-source web projects. Some of the reasons behind this include: Managing native solutions for iOS and Android platforms would demand extra engineering effort. The support and documentation available for three.js surpass others. The web view solution delivers native-like performance by using WebGL on both platforms. As a result, we consistently achieve 60/120 FPS across all scenes on both devices. The plan was simple. Build simple HTML files that render 3D scenes and load these files locally in mobile apps 🚀 But we had a "huge" problem... The 3D models were specifically designed for static illustrations, resulting in a high polygon count that contributes to larger file sizes. For instance ## Grafana Mimir Compaction: From Bottleneck to Savings DevFeed: [Grafana Mimir Compaction: From Bottleneck to Savings]() Original publisher: [Read original article]() Author: Milon James Published: 2025-01-15T11:55:57Z Content type: article Language: en Sources: [Wise Engineering - Medium]() Topics: [Grafana](), [observability](), [Scalability](), [Multi-tenancy](), [Architecture & Design](), [Latency](), [Disk image]() Tags: [architecture](), [grafana](), [grafana-mimir](), [metrics](), [multi-tenancy](), [observability](), [performance](), [platform](), [platform-engineering](), [s3](), [scalability]() ### AI overview This technical article describes Wise's migration from Thanos to Grafana Mimir, the compaction bottleneck that emerged in its metrics infrastructure, and the resulting improvements after the issue was resolved. The reported benefits include S3 storage savings, reduced cross-AZ network transfer, and lower query latency. ### Source excerpt Intro This technical blog article dives deep into a compaction bottleneck that was silently impacting our metrics infrastructure after we migrated from Thanos to Grafana Mimir. Follow along as we detail the investigation, solution, and the remarkable performance and cost improvements that transformed our metrics pipeline. To give readers some context on the scale of our operations at Wise, our production Mimir stack is currently ingesting approximately a total of 6 million metric samples per second across different tenants at the time of writing -- a testament to the critical role it plays in our observability infrastructure. Write throughput and latency In the world of observability, managing large-scale metric storage systems can be a challenging endeavour. Recently, Wise made a significant shift from Thanos to Grafana Mimir, a decision driven by our growing need for better scalability, feature richness, and operational simplicity. The switch has already yielded several benefits, but a critical issue with Mimir compaction brought new challenges to light. Once resolved, this fix not only improved system reliability but also delivered substantial cost benefits in terms of S3 storage savings, cross-AZ network transfer reductions, and query latency improvements. Here's an overview of our journey -- from the switch to Mimir to resolving compaction issues and reaping the rewards. Why We Switched from Thanos to Mimir Thanos had served us well as a metrics storage and query system, but as our use case evolved, we began to encounter limitations: Scaling Challenges: Managing Thanos components at scale -- especially with the growth in the volume of metrics data -- became operationally complex. Retention and Compaction Flexibility: Thanos's approach to compaction and retention felt rigid for our growing requirements. Feature Set: Mimir provided robust multi-tenancy capabilities, advanced query performance optimisations, and seamless integration with our existing workflows. Benefi ## Measuring meaningful availability / uptime of Wise DevFeed: [Measuring meaningful availability / uptime of Wise]() Original publisher: [Read original article]() Author: Dániel Élő Published: 2024-08-30T08:24:13Z Content type: article Language: en Sources: [Wise Engineering - Medium]() Topics: [Availability](), [systems](), [API]() Tags: [api](), [availability](), [high-availability](), [http](), [measurement](), [monitoring](), [platform](), [systems](), [uptime]() ### AI overview Wise explains how it is developing a meaningful way to measure and report product availability and uptime based on user-experienced business flows, while acknowledging that a single aggregate figure is an approximation. ### Source excerpt At Wise we're building the best way to move and manage the world's money -- making it faster, cheaper, convenient and transparent. Product uptime and availability is contributing to three parts of our mission: An honest and meaningful uptime report is key to drive transparency of our systems. High availability is one of the greatest factors in making our product convenient. It is very hard to be convenient if the product is not working as designed. High availability means less retries and less waiting, driving us closer to instant too. In this post we will talk about the reporting aspect of uptime and availability, focusing on transparency. We would like to share our journey and various technical considerations towards measuring meaningful availability/uptime for Wise. Wise has a wide range of product offerings, condensing the availability or uptime of our business flows is not trivial. These flows consist of multiple business operations with various branches depending on user intent or group. Providing a single number as business flow availability or uptime is always going to be an approximation, but we can and should be transparent about how we aggregate and what that represents. Our goal is to have a meaningful measurement we can get behind as representative of user-experienced uptime/availability. Definitions First things first, let's define some terms we'll use: Business flow: A high level, complex use-case of the Wise product, e.g. "send money" (we aim to measure the availability of this, as this is the most meaningful for the end-users) Business operation: an individual operation a user can perform as part of one use case or business flow. A high level piece of functionality e.g. get a quote, set up a transfer, pay in for the transfer API endpoint: a technical term. Which HTTP(S) API to invoke in order to perform a Business operation. Not a service or a series of calls, a single HTTP(S) endpoint to perform a (part or whole) of Business operation. Availability: ## Avoiding Kubernetes Pod Topology Spread Constraint Pitfalls DevFeed: [Avoiding Kubernetes Pod Topology Spread Constraint Pitfalls]() Original publisher: [Read original article]() Author: Matthew Kennedy Published: 2023-03-28T09:12:41Z Content type: tutorial Language: en Sources: [Wise Engineering - Medium]() Topics: [Kubernetes](), [configuration](), [Availability](), [resiliency](), [Amazon Web Services](), [Cloud]() Tags: [availability](), [aws](), [cloud](), [configuration](), [devops](), [kubernetes](), [kubernetes-clusters](), [pitfalls](), [platform-engineering](), [resiliency](), [software-engineering]() ### AI overview This article explains how Kubernetes Pod Topology Spread Constraints distribute workloads across Availability Zones or nodes. It examines how naive configurations can create unexpected pod skew and potentially cause the loss of two-thirds of pods if one Availability Zone fails. ### Source excerpt In the Wise Cloud Platform squad we take resiliency, capacity planning and costs seriously. We are always looking for ways to improve how services running on our self-managed Kubernetes clusters in AWS can be made more resistant to system failures without significantly increasing cost. One of the mechanisms we use are Pod Topology Spread Constraints. This is a built-in Kubernetes feature used to distribute workloads across a topology domain, such as Availability Zones or Nodes. In this blog post, we consider Availability Zones to be our topology domain. We discuss how to configure Pod Topology Spread Constraints correctly and how a naive configuration creates unexpected Pod skew. If Pod Topology Spread Constraints are misconfigured and an Availability Zone were to go down, you could lose 2/3rds of your Pods instead of the expected 1/3rd. This will likely negatively impact your customers' ability to use your product. What is wrong with Kubernetes Pod Topology Spread Constraints? Skew is the difference in the number of pods between the most populated and least populated Availability Zone. If we have 3 Availability Zones and 3 Pods, ideally we want a skew of 0, as seen in the diagram below. Diagram showing skew of 0 If we were to add another pod, it could be placed in any of the Availability Zones and our pods would still be distributed as evenly as possible. Our skew would then be 1. If the pods are not evenly distributed, the skew will always be greater than 1. In the case of the diagram below, Availability Zone 1 contains 2 pods and Availability Zone 3 contains zero pods, so the skew is 2. Diagram showing skew of 2 You can configure the Pod Topology Spread Constraints through the topologySpreadConstraints section of a Pods' spec. The Pods to which the configuration is applied is determined through LabelSelectors and what you deem an acceptable distribution is determined by the maxSkew field. Below is an example of a naive topologySpreadConstraints configuration: api ## How Wise bootstraps Spinnaker using ArgoCD DevFeed: [How Wise bootstraps Spinnaker using ArgoCD]() Original publisher: [Read original article]() Author: Nick Platt Published: 2023-02-20T12:24:46Z Content type: tutorial Language: en Sources: [Wise Engineering - Medium]() Topics: [argocd](), [spinnaker](), [CI/CD](), [GitOps](), [Kubernetes](), [Microservice](), [Deployment](), [Helm charts](), [Java]() Tags: [argo-cd](), [argocd](), [ci-cd](), [continuous-delivery](), [deployment](), [gitops](), [helm-charts](), [kubernetes](), [microservices](), [platform](), [spinnaker]() ### AI overview Wise explains how it bootstrapped Spinnaker automatically with ArgoCD instead of using a staging Spinnaker to manage production. The article compares Spinnaker's pipeline-based deployment model with ArgoCD's declarative GitOps reconciliation model and describes using ArgoCD and its App of Apps pattern to manage Spinnaker installations across Kubernetes clusters. ### Source excerpt Spinnaker and ArgoCD logos Deploying your deployment tool In our 2 part series, we discussed the state of our CI/CD systems and wrapped up with our vision for CD at Wise, and why we chose Spinnaker. Here's how we set up Spinnaker from scratch, overcoming the technical challenges of bootstrapping a CD platform. We wanted a hands-off and automated way to bootstrap Spinnaker. When researching across industry peers, one approach was to use a staging instance of Spinnaker to manage your production instance. This method of dual Spinnakers, wasn't viable for Wise, due to security concerns with a staging tool having access to change a production environment. It also meant accepting a potentially manual error prone process when managing your staging setup. Instead, we wanted to achieve a fully automatic installation for both of our Spinnaker environments and settled on using ArgoCD. Spinnaker & ArgoCD Spinnaker consists of around 11 Java microservices, which operates on a centralised deployment model -- push based deployments. It utilises pipelines heavily as its deployment strategy, which can be triggered via various input methods e.g. manual, artefact upload etc. Implementing deployments as pipelines allows engineers to describe a release as a set of steps, with powerful concepts such as canary analysis and quality gates built in. This is attractive for Wise, as use of standardised and reusable templates can enforce end consumers to follow a particular paved road e.g. canary deployments with automatic rollbacks. ArgoCD describes itself as "declarative GitOps for Kubernetes". It comprises fewer golang microservices and can be configured to be either centralised or decentralised. By default, ArgoCD differs by not utilising pipeline based deployments, instead operating via a GitOps reconciliation loop as its source of truth. Whatever is defined in Git, ArgoCD will try to reconcile within the cluster. ArgoCD is Kubernetes native and therefore can't be used for deploying infrast ## Improving the Developer Experience -- Our Application Security Journey (Part 3) DevFeed: [Improving the Developer Experience -- Our Application Security Journey (Part 3)]() Original publisher: [Read original article]() Author: Florian Wirtz Published: 2023-01-17T11:19:44Z Content type: article Language: en Sources: [Wise Engineering - Medium]() Topics: [Application Security](), [Developer experience](), [vulnerability management](), [dashboards](), [software composition analysis](), [trivy]() Tags: [application-security](), [dashboards](), [developer-experience](), [platform](), [security](), [software-composition-analysis](), [trivy](), [vulnerability-management]() ### AI overview This third article in Wise's application security series examines how to improve developers' experience when fixing vulnerabilities. It describes feedback gathered through surveys and interviews, identifying slow dashboards and the need for developers to proactively check them as key pain points. ### Source excerpt Improving the Developer Experience -- Our Application Security Journey (Part 3) This is the third in a series of articles on the state of Application Security at Wise, describing our integration of security in the Software Development Lifecycle. Photo by Possessed Photography on Unsplash In part three of our blog post series we will be focusing on how we can improve the developers' experience around fixing vulnerabilities. We explore how we identified the main pain points developers were facing, what we did to improve this experience and future improvement ideas that we are planning to work on. Recap: What happened so far? Over the course of the last year we have created our new setup for identifying vulnerabilities at Wise. It's centred around DefectDojo as our vulnerability management tool and we use scanners, such as Trivy for Software Composition Analysis, as inputs. You can learn more about our setup in part one of this blog series. Since then we have also created various dashboards to report vulnerabilities to our stakeholders, and also improved our Service-level agreement (SLA) with our developers to resolve new vulnerabilities. To learn more about that, please read part two of this series. What issues are our developers facing? As a next step, it's important to check in with our developers to see how they're interacting with our program. It's one thing to set up a vulnerability management program, but we also need to make sure that it actually works for our users and that the recommendations provided are actioned in a timely manner. While the initial feedback we received from developers was promising, we decided to share a survey with them to collect more actionable feedback. Our survey had a mix of multiple-choice and free-form questions and was mostly focused on how developers are using our tools and what issues they might be facing with them. We also interviewed them for analogous use cases, including what works well and what doesn't work well in other too ## How we Integrated SPIFFE, Oauth2.0 and Spring Boot DevFeed: [How we Integrated SPIFFE, Oauth2.0 and Spring Boot]() Original publisher: [Read original article]() Author: Matthew Benedict Stocks Published: 2022-12-14T09:36:48Z Content type: tutorial Language: en Sources: [Wise Engineering - Medium]() Topics: [SPIFFE](), [Authorization](), [OpenID connect (OIDC)](), [SPIRE](), [Library](), [Security](), [Spring Boot]() Tags: [authorization](), [cybersecurity](), [library](), [oauth2](), [platform](), [security](), [service-mesh](), [spiffe](), [spring-boot]() ### AI overview Wise's Security Engineering team describes how it consolidated SPIFFE/SPIRE and OIDC authorization strategies into the wise-security shared library. The approach reduces Spring Security boilerplate, presents a consistent service-layer security context, and adds guardrails intended to reduce misconfiguration and authorization complexity. ### Source excerpt How we Integrated SPIFFE, OAuth2 and Spring Boot At Wise the Security Engineering team supports the Security Squad by developing tools and building technical controls relevant to the security maturity of existing technological setup. We work closely with teams across Platform and Product to help improve our overall security posture and reduce the friction encountered when engineering new software at speed. Photo by Jason Dent on UnsplashThe problem As a company we have a goal of reducing the amount of time it takes to go from inception to creation with our services. We want teams across Wise to be able to focus on the challenges encountered in their domain, rather than cross-cutting concerns, such as how to secure their endpoints. At Wise our approach was to create a common shared library, allowing teams to share our security solution while still retaining their autonomy. Standard security setups such as those seen with Spring Security often require a lot of boilerplate code (even if provided as part of a service template) which we wanted to reduce and where possible, abstract it entirely. Along with improving the quality of life for new and experienced engineers within Wise, this also helps to prevent any misconfiguration that could eventually lead to a vulnerability. Another challenge which arose was to offer a security context that appears the same at the service layer, but can be created from any of the protocols used by our systems, as well as being extensible if necessary. We needed to allow developers to control access to services with minimal effort, alongside creating a security guardrail for exposed endpoints to ensure services have been configured correctly. Introducing Wise Security At Wise, our service mesh layer is handled by Envoy and the identity framework for secure communication between mesh nodes is SPIFFE/SPIRE. User based IAM is handled via the OIDC authorization protocol. Each authorization approach must be enforced at the service layer, but du ## Wise Tech Stack (2022 edition) DevFeed: [Wise Tech Stack (2022 edition)]() Original publisher: [Read original article]() Author: pavel dionisev Published: 2022-12-07T08:04:11Z Content type: article Language: en Sources: [Wise Engineering - Medium]() Topics: [Back end](), [Microservices](), [Java](), [Spring Boot](), [Front end](), [Mobile](), [API](), [Kotlin](), [Next.js](), [Development]() Tags: [backend](), [frontend](), [java](), [jvm](), [kotlin](), [microservices](), [mobile](), [next-js](), [platform](), [spring-boot](), [tech](), [tech-stack]() ### AI overview Wise describes its 2022 technology stack, including microservices across backend, frontend, and mobile applications. Most backend services run on the JVM using Spring Boot and Java or Kotlin, while customer-facing applications use a framework built on Next.js. ### Source excerpt Intro Two years passed since our last tech stack post. TransferWise became Wise and Wise became a public company. We've opened more offices in more locations and remote work was never as common. We faced more regulatory scrutiny, went through multiple audits, and proved to the world and our customers that we are trustworthy, and still laser focused on helping money move without borders. We kept going, kept opening new routes and launching new products, all in the new paradigm. Most importantly, we did it without slowing down, introducing extra complexity or bureaucracy to our processes. In this blog post we'll share how we achieved it. Photo by Sean Stratton on UnsplashProduct: Backend Microservices, Frontend, mobile and API Our product is at the core of what we do and it roughly consists of customer-facing frontend and mobile applications, and complex backend machinery that works under the hood to support our mission: money without borders -- instant, convenient, transparent and eventually free. It is not a small task. Luckily, we have more than 700 engineers forming approximately 100 teams that are very good at solving the problems that arise. Our stack follows that structure. We use microservices in backend, frontend and our mobile apps are also modularised to a small chunks owned by specific teams. Most of our over 600 backend services are running on JVM, use Spring Boot and written in Java or, sometimes, Kotlin. Early on we decided to encourage anyone to contribute to any service we have. To achieve that we needed to reduce the entry barrier, so common language as a foundation worked really well. Sticking to industry standard allows us to tap into a wide and diverse pool of engineers that can join us on our mission. Common, compatible runtime also enabled us to work on standardisation, and building tools and libraries that support each engineer: standardised observability, security, service-to-service communications and more. We abstracted a lot of underlying in