{
  "id": 17564148,
  "title": "No cloud to lean on: building a reliable data platform on a bank's own servers",
  "url": "https://urgent.news/2026/11/01/no-cloud-to-lean-on-building-a-reliable-data-platform-on-a-banks-own",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-01T08:35:07.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mashaa/no-cloud-to-lean-on-building-a-reliable-data-platform-on-a-banks-own-servers-2i2k"
  },
  "original_language": "en",
  "account": "The article discusses the challenges of building a reliable data platform on a bank's own servers, using Kubernetes and avoiding managed services. The goal was to ensure no data is lost, and the system stops no work for more than a few seconds. The platform's functionality was to process file uploads through a web portal, clean the files, load them into an Iceberg data lake using Spark, and reconcile transactions across sources. All communication between services occurred through a message queue.\n\nKey aspects include:\n\n1. Reliability: The system acknowledges work only after it is completed, preventing double lock acquisition and ensuring files are not dropped during shutdown.\n2. Fault tolerance: Replicated databases and queues, automatic failover, and failure containment were implemented. If a service fails, it leaves messages waiting in the queue, preventing data loss.\n3. High availability: The system aims to minimize user impact by having seconds of downtime for a lost server and zero downtime for upgrades and node maintenance.\n4. Scalability: Replica counts follow queue depth, with heavy jobs waiting for available resources instead of failing.\n5. Observability: Alerts via email, searchable logs, dashboards, and daily health reports were set up to monitor the system.\n\nThe platform's design follows the rule that no work is lost silently, meaning messages are only acknowledged after completion. A message broker like RabbitMQ is used, with quorum queues that drop messages after failed deliveries and dead-letter queues for unrecoverable messages. The platform also includes measures to handle memory issues, such as setting memory limits based on the largest input and monitoring for OOM kills.",
  "summary": "Replication, failover, graceful shutdown, autoscaling and alerting usually arrive as managed services. Inside a bank, you build them from Kubernetes, an operator or two and a lot of small decisions. Here is how each one works, with the code. Field notes from moving a transaction reconciliation platform from AWS onto Kubernetes inside banks' data centres The constraints Five words, one goal…",
  "key_points": [
    "Bank builds reliable data platform on its own servers using Kubernetes.",
    "System processes file uploads, cleans files, loads into Iceberg data lake.",
    "Measures reliability, fault tolerance, high availability, scalability, and observability."
  ],
  "editors_take": "Prioritizing self-hosted infrastructure over managed cloud services forces engineers to build complex fault tolerance and automated failover mechanisms to ensure data integrity and continuous availability during server failures.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}