Skip to main content
Portfolio
Back to Portfolio
Digital Banking & Lifestyle Super AppLive · Active Development

Dashen Super App

Ethiopia's most comprehensive digital banking super app, consolidating payments, chat banking, e-commerce, budgeting analytics, and lottery into a single platform for Dashen Bank's customer base. The system serves tens of thousands of active users under strict financial-grade reliability requirements.

Client

Dashen Bank · Eagle Lion System Technology

My Role

Backend Developer

Timeline

Feb 2025 – Present

Status

Live · Active Development

GoNode.jsKafkaRabbitMQRedisKubernetesDockergRPCPostgreSQLMongoDBScyllaDBAWS
Dashen Super App
The Problem

Dashen Bank needed a unified digital platform to compete with global super apps while satisfying the compliance and reliability requirements of regulated banking. The challenge: integrate five separate product domains — payments, e-commerce, chat banking, budgeting, lottery — with a shared identity layer, without compromising the transaction integrity a bank demands.

System Architecture

Domain-bounded microservices communicating through a dual-broker event layer. gRPC for synchronous, latency-sensitive operations. Kafka for the high-throughput financial event stream. RabbitMQ for reliable task queuing requiring guaranteed exactly-once delivery semantics.

API Gateway

Routes mobile and web traffic, enforces authentication, rate limiting, and request validation before passing to upstream services.

GoJWT / OAuth2Rate Limiter
Core Services

Payment, E-commerce, Chat Banking, Lottery, and Budgeting — each deployed as an independent Go service with its own data store.

GogRPCREST
Event Streaming

Kafka handles the financial event backbone. RabbitMQ manages task queues with dead-letter queue support for failed message recovery.

KafkaRabbitMQConsumer Groups
Data Layer

Service-owned databases enforce domain isolation. Redis caches hot-path reads and manages distributed session state.

PostgreSQLMongoDBRedisScyllaDB
Infrastructure

Containerized workloads on Kubernetes with rolling deployments, readiness probes, and auto-scaling for traffic spikes.

KubernetesDockerCI/CDAWS
My Contributions
  • 1

    Designed the backend service topology — defining service boundaries, ownership contracts, and inter-service communication patterns across five product domains.

  • 2

    Built the event-driven core using Kafka topics and RabbitMQ queues, ensuring no financial event is lost even under service failure through idempotent consumer design.

  • 3

    Led the internal API design: gRPC service contracts for the service mesh, REST endpoints for mobile client integration.

  • 4

    Implemented the payment orchestration service handling fund transfers, wallet top-ups, merchant payments, and transaction status tracking.

  • 5

    Defined Kubernetes deployment manifests, resource limits, health check probes, and rolling update strategies for zero-downtime production rollouts.

Engineering Challenges

Financial Transaction Consistency Across Services

Multi-step financial operations must be atomic or fully compensated. Implemented the saga pattern: each step publishes an event to Kafka, and rollback consumers handle partial failures — eliminating distributed transaction locks while preserving end-to-end correctness.

Per-User Event Ordering at High Throughput

Lottery events, payment confirmations, and e-commerce updates needed strict per-user ordering without global sequencing bottlenecks. Solved by partitioning Kafka topics by user ID, giving per-user ordering with horizontal throughput scaling.

Zero-Downtime Deployments for Financial Services

Active payment flows cannot tolerate cold-start downtime. Configured Kubernetes readiness probes checking gRPC health endpoints before routing live traffic, combined with rolling deployment strategies keeping old pods alive until new ones fully pass health checks.

Results & Impact

Platform serving tens of thousands of active registered users across Ethiopia

Five product domains — payments, e-commerce, lottery, chat banking, budgeting — unified under a single identity layer

Zero-downtime deployments achieved across all services on Kubernetes

Financial events processed with at-least-once delivery guarantees via Kafka consumer groups with idempotent handlers

Key Takeaway

The hardest part of a super app backend isn't any individual service — it's maintaining their independence. Every shortcut crossing service boundaries becomes debt that limits your ability to scale domains independently. Strict ownership contracts and event-driven integration are not optional in financial systems; they are the architecture.