Java Senior Developer / Software Architect — Microservices Spring Boot Webhooks + Auto-Updating Desktop Client
Budget: $250 – $750 USD
We’re looking an experienced Java engineer (or small team) to build two coordinated pieces:
A Spring Boot microservice (Tomcat) that exposes/consumes webhooks and provides reliable, secure, real-time event delivery between a cloud app and desktop clients.
A Windows desktop updater/launcher for an always-running Java JAR (the desktop application) that can receive updates pushed from the cloud, apply them with no manual intervention, and retain user parameters (session id, username/password or token). Wrapping the launcher as a native .exe is a bonus.
Project Summary
==============
Build a production-ready Spring Boot microservice and a matching desktop update/launcher system that together provide secure, low-latency, and reliable cloud→desktop event delivery and automated desktop software upgrades. The solution must preserve user parameters and support seamless updates with verification (checksums/signatures) and graceful restart semantics.
Core Stack
=========
Java 17+
Spring Boot (latest stable) with Tomcat
Maven
JSON for messages (OpenAPI / Swagger)
Security: JWT / OAuth2 for API/webhook authentication
Testing: JUnit 5, Mockito, Testcontainers for integration tests
Optional: Docker, Kubernetes YAML
Functional Requirements
==============
--Microservice
--Webhook Listener & Sender
--Endpoints to receive incoming webhooks and to dispatch events to registered desktop clients.
--Support HMAC or JWT signing for webhook verification.
--Configurable retry/backoff policy, idempotency for delivery, dead-letter handling.
--Subscription management (register/deregister desktop endpoints, event types, custom headers).
--Real-time Cloud→Desktop Delivery
--Reliable push of events to desktop clients via webhooks or message queue (RabbitMQ/Redis/Kafka optional).
--Ensure guaranteed-at-least-once delivery semantics with dedup/idempotency strategies.
State & Scalability
==================
--Stateless API layer; any ephemeral state stored in in-memory caches (ConcurrentHashMap/Caffeine) or persistent store if needed.
---Horizontal scaling friendly (sticky state not required).
—Security OAuth2 or JWT for API endpoints and webhook authentication. TLS for all network traffic.
--Role-based access control for admin endpoints.
--Observability & Operations
Structured logging (SLF4J / Logback).
Metrics via Micrometer (Prometheus compatible).
Health checks, readiness and liveness endpoints.
Distributed tracing hooks (optional; OpenTelemetry compatible).
Desktop updater/launcher
Always-running app constraints
Desktop app stays running normally; updates must not corrupt user session data.
User parameters (32-bit session id, username, password or token) must persist outside the JAR (config file, encrypted store, or OS user profile) so updates do not lose them.
Update flow
Launcher or lightweight updater process checks update manifest on server (version + checksum/signature + download URL).
Supports safe download to temp location, checksum/signature verification, atomic swap of the JAR.
Graceful restart: app saves state -> updater stops app -> replace JAR -> restart app automatically.
If impossible to fully avoid restart, minimize downtime and ensure automatic resume of session using persisted session tokens.
Security & Integrity
Verify updates using checksums (SHA-256) and/or digital signatures.
Use HTTPS for downloads, validate certificates.
Optionally require mutual TLS or signed manifests.
Native Packaging (bonus)
Provide instructions or tooling to wrap launcher as .exe (Launch4J, jpackage, or similar), Windows installer if desired.
Non-Functional Requirements
====================
Performance: webhook dispatch latency < 50-200ms typical; support 1k+ concurrent client connections in typical deployment.
Reliability: retries/backoff and dead letter for failed deliveries.
Security: secrets not stored in plaintext; credentials encrypted at rest.
Maintainability: clean layered architecture, modular, documented.
Testability: unit and integration coverage ≥ 80%.
Deliverables
==============
--Source code repo (GitHub/GitLab) with branches, CI pipeline (GitHub Actions or similar).
—Microservice
-------Complete Spring Boot app with controllers, services, repositories (or cache), security config.
-------OpenAPI / Swagger docs.
-------Dockerfile and (optional) Kubernetes YAMLs.
--Desktop updater/launcher
-------Java launcher/updater implementation (updater.jar and instructions for packaging as .exe).
-------Example config storage pattern for session/credentials (encrypted).
-------Sample update manifest & server layout for hosting updates.
--Tests
-------Unit tests and integration tests (Testcontainers for DB if used).
-------Acceptance tests for update flow (download, verify, swap, restart).
--Docs
-------Design doc explaining architecture and tradeoffs.
-------Setup & deployment guides (local + cloud).
-------Security checklist (how updates are verified and how secrets are stored).
--Optional
Example client (desktop) stub demonstrating receiving webhooks and triggering update.
Helm chart for Kubernetes.
A Spring Boot microservice (Tomcat) that exposes/consumes webhooks and provides reliable, secure, real-time event delivery between a cloud app and desktop clients.
A Windows desktop updater/launcher for an always-running Java JAR (the desktop application) that can receive updates pushed from the cloud, apply them with no manual intervention, and retain user parameters (session id, username/password or token). Wrapping the launcher as a native .exe is a bonus.
Project Summary
==============
Build a production-ready Spring Boot microservice and a matching desktop update/launcher system that together provide secure, low-latency, and reliable cloud→desktop event delivery and automated desktop software upgrades. The solution must preserve user parameters and support seamless updates with verification (checksums/signatures) and graceful restart semantics.
Core Stack
=========
Java 17+
Spring Boot (latest stable) with Tomcat
Maven
JSON for messages (OpenAPI / Swagger)
Security: JWT / OAuth2 for API/webhook authentication
Testing: JUnit 5, Mockito, Testcontainers for integration tests
Optional: Docker, Kubernetes YAML
Functional Requirements
==============
--Microservice
--Webhook Listener & Sender
--Endpoints to receive incoming webhooks and to dispatch events to registered desktop clients.
--Support HMAC or JWT signing for webhook verification.
--Configurable retry/backoff policy, idempotency for delivery, dead-letter handling.
--Subscription management (register/deregister desktop endpoints, event types, custom headers).
--Real-time Cloud→Desktop Delivery
--Reliable push of events to desktop clients via webhooks or message queue (RabbitMQ/Redis/Kafka optional).
--Ensure guaranteed-at-least-once delivery semantics with dedup/idempotency strategies.
State & Scalability
==================
--Stateless API layer; any ephemeral state stored in in-memory caches (ConcurrentHashMap/Caffeine) or persistent store if needed.
---Horizontal scaling friendly (sticky state not required).
—Security OAuth2 or JWT for API endpoints and webhook authentication. TLS for all network traffic.
--Role-based access control for admin endpoints.
--Observability & Operations
Structured logging (SLF4J / Logback).
Metrics via Micrometer (Prometheus compatible).
Health checks, readiness and liveness endpoints.
Distributed tracing hooks (optional; OpenTelemetry compatible).
Desktop updater/launcher
Always-running app constraints
Desktop app stays running normally; updates must not corrupt user session data.
User parameters (32-bit session id, username, password or token) must persist outside the JAR (config file, encrypted store, or OS user profile) so updates do not lose them.
Update flow
Launcher or lightweight updater process checks update manifest on server (version + checksum/signature + download URL).
Supports safe download to temp location, checksum/signature verification, atomic swap of the JAR.
Graceful restart: app saves state -> updater stops app -> replace JAR -> restart app automatically.
If impossible to fully avoid restart, minimize downtime and ensure automatic resume of session using persisted session tokens.
Security & Integrity
Verify updates using checksums (SHA-256) and/or digital signatures.
Use HTTPS for downloads, validate certificates.
Optionally require mutual TLS or signed manifests.
Native Packaging (bonus)
Provide instructions or tooling to wrap launcher as .exe (Launch4J, jpackage, or similar), Windows installer if desired.
Non-Functional Requirements
====================
Performance: webhook dispatch latency < 50-200ms typical; support 1k+ concurrent client connections in typical deployment.
Reliability: retries/backoff and dead letter for failed deliveries.
Security: secrets not stored in plaintext; credentials encrypted at rest.
Maintainability: clean layered architecture, modular, documented.
Testability: unit and integration coverage ≥ 80%.
Deliverables
==============
--Source code repo (GitHub/GitLab) with branches, CI pipeline (GitHub Actions or similar).
—Microservice
-------Complete Spring Boot app with controllers, services, repositories (or cache), security config.
-------OpenAPI / Swagger docs.
-------Dockerfile and (optional) Kubernetes YAMLs.
--Desktop updater/launcher
-------Java launcher/updater implementation (updater.jar and instructions for packaging as .exe).
-------Example config storage pattern for session/credentials (encrypted).
-------Sample update manifest & server layout for hosting updates.
--Tests
-------Unit tests and integration tests (Testcontainers for DB if used).
-------Acceptance tests for update flow (download, verify, swap, restart).
--Docs
-------Design doc explaining architecture and tradeoffs.
-------Setup & deployment guides (local + cloud).
-------Security checklist (how updates are verified and how secrets are stored).
--Optional
Example client (desktop) stub demonstrating receiving webhooks and triggering update.
Helm chart for Kubernetes.