Skip to content
Sahil Swain
← All work
Professional experienceExperience-backed

Enterprise Backend Engineering

Professional case study

A multi-microservice financial file-ingestion platform — the Issuer Shared Service / CitiBank Data Lake — involving Java 17, Spring Boot, AWS S3, Apache Kafka, MySQL, Flyway, Docker and Helm.

What problem existed?

Financial file ingestion needs to be secure, trackable, and recoverable: files must be verified, tracked through a pipeline, and retried cleanly when things fail.

Context / constraints

  • Professional experience case study from work at HCL Technologies (Lead Engineer, May 2025 – Sep 2025), described only at a non-confidential level supported by the résumé.
  • Stack: Java 17, Spring Boot, Microservices, AWS S3, Apache Kafka, MySQL, Flyway, Docker, Helm, Autosys.
  • The architecture shown here is a generalized public pattern, not an exact client topology.

What was built

  • Secure file-ingestion workflow with S3 access verification before processing.
  • File metadata and pipeline tracking so every ingested file has an inspectable lifecycle.
  • Orchestrator and client services (BanzaiUploadService, BanzaiTriggerService) with exception handling and retry logic.
  • Flyway-managed schema migrations and automated scheduling.

Architecture

  • Résumé-supported responsibilities include S3 access verification, metadata and pipeline tracking, service orchestration, retry handling, migrations, scheduling, and deployment collaboration.
  • Kafka, MySQL, Docker, Helm, ECS, and Autosys are shown as approved technology context only; the diagram does not claim how they were connected inside the client system.
GENERALIZED PUBLIC PATTERN · NOT CLIENT TOPOLOGYFile ingestionsecure intakeAccess verificationS3 permissionsMetadata trackingpipeline lifecycleService orchestrationupload · triggerReliabilityretry · exceptionsPersistenceMySQL · FlywayMessaging contextApache KafkaDelivery contextHelm · ECS · AutosysRésumé-supported responsibilities and technology context only.Connections, hosts, and internal deployment topology are intentionally not shown.

Scroll horizontally to inspect the diagram at a readable size.

Key engineering decisions

  • Verify S3 access before processing so permission failures surface immediately.
  • Track file metadata and pipeline state explicitly instead of inferring it from logs.
  • Design retry and exception handling as first-class behavior, not an afterthought.

Validation / tests

  • Raised JaCoCo test coverage on the owned services from ~40% to 80%+ (engineering metric, per résumé).
  • JUnit 5 / Mockito unit tests and integration testing as part of the delivery workflow.

What is deliberately not claimed

  • No exact confidential client architecture or component topology is disclosed or claimed.
  • No confidential implementation details, internal hostnames, credentials, customer-sensitive data, or proprietary business rules are disclosed.
  • The test-coverage figure is an engineering metric on owned services — not a client-wide business outcome.

Want this kind of system built for your workflow?

Start a project