Spring Boot and Firebase Cloud Messaging for Push Notifications
Push notifications have become the lifeblood of mobile engagement, from banking apps in Sydney to retail platforms in Melbourne. When the backend is built with Spring Boot and the audience spans Android, iOS, and the web, Firebase Cloud Messaging offers a unified transport that scales without forcing you to manage queues, sockets, or device registries. This guide walks through wiring a Spring Boot service to the FCM HTTP v1 API, dispatching targeted payloads, and handling the quirks that Australian projects tend to encounter, including cross-time-zone delivery windows and the strict consent expectations of local consumers.
Developers in Brisbane and Adelaide have increasingly adopted FCM because the same payload can address Android handsets, iPhones, and browser tabs without maintaining separate providers. A typical Spring Boot microservice can register a Firebase service account once, cache the OAuth 2.0 access token, and dispatch messages through a small REST client. The rest of this article covers that flow end to end, including topic subscriptions, conditional sends, and a comparison of the main delivery strategies you might weigh for your own project.
Preparing the Firebase Project and Service Account
Before any Java code runs, head to the Firebase console and create a project, or attach a new app to an existing Google Cloud organisation. Once the app is registered, open Project Settings, switch to the Service Accounts tab, and click Generate New Private Key. The downloaded JSON file holds the project identifier, client email, and private key that Spring Boot will use to sign tokens for the FCM endpoint.
In a production-grade Spring Boot application, store the JSON outside the jar so secrets never leak through a code repository. A common pattern across Australian teams is to mount the file through a Kubernetes secret or read it from a cloud parameter store, then expose its path through an environment variable. The service loads it during startup, builds a GoogleCredentials object, and registers a FirebaseMessaging bean that other components can inject.
Wiring FCM into a Spring Boot Application
Add the official Firebase admin SDK to your Maven or Gradle build. The artifact firebase-admin already bundles the HTTP client, OAuth helpers, and message builders, so no extra transport library is required. Configure a configuration class that reads the service account path from properties, instantiates FirebaseOptions with the credential, and exposes a singleton FirebaseMessaging instance.
Because the SDK mints short-lived access tokens, caching happens internally, yet you should still tune HTTP timeouts and retry budgets to survive flaky links in regional Australia. Many engineers in Melbourne set a five-second connect timeout and a fifteen-second read timeout, which feels generous compared to the typical fibre links in capital cities but covers rural edge cases when staff test from a remote farm or mining site.
Sending Your First Push Notification
With the bean in place, create a service component that accepts a device token, a title, and a body, then returns the FCM message identifier. The Message.builder() API lets you compose the notification, supply a data map for custom payload fields, and set priority and TTL values. For a banking alert such as "Card transaction at Coles Sydney CBD", you would set a high priority so the message arrives within seconds.
A controller can expose this behind a POST endpoint, validate the incoming JSON, and forward it to the service. Logging the message name returned by FCM helps your support team in Perth trace a delivery when a customer calls about a missed alert. Returning the result through a ResponseEntity lets the caller react to FCM errors rather than receiving a generic 200 OK.
Topic, Multicast, and Condition-Based Delivery
Beyond one-to-one sends, FCM supports topic subscriptions, where devices opt in to a logical channel such as afl-melbourne or interest-rate-update. A Spring Boot scheduler can broadcast the same message to thousands of subscribers with a single API call, which is far cheaper than looping through individual tokens. The downside is that topic messaging does not return per-device results, so you cannot confirm delivery to a specific user.
When guaranteed delivery to a known audience matters, the multicast API accepts up to 500 tokens per request and returns a per-token success map. Condition expressions let you mix topics, for example weather-sydney in topics:syd-flood-watch, which is useful for emergency broadcasting in New South Wales. Choosing between these approaches depends on your scale, your need for delivery receipts, and how much client-side logic you can rely on.
Comparing the Main Delivery Strategies
The table below summarises when each approach makes sense for a Spring Boot service.
| Strategy | Best for | Token limit per call | Per-device feedback | Typical use case |
|---|---|---|---|---|
| Single send | Critical alerts to one user | 1 | Yes | Banking OTP, ride updates |
| Multicast | Known audience up to 500 | 500 | Yes | Daily summary to active users |
| Topic broadcast | Massive opt-in segments | Unlimited | No | Sports scores, breaking news |
| Condition send | Cross-topic logic | Unlimited | No | Emergency alerts, geo events |
Topic and condition sends are ideal for high-volume publishers such as news outlets or transport agencies, where individual receipts matter less than reaching everyone quickly. Multicast remains the workhorse for marketing-style campaigns where you want to know exactly which devices bounced. Single sends are reserved for transactional messages such as two-factor authentication, where a missed push is a support ticket waiting to happen.
When designing a new feature, weigh the trade-offs against the expectations of Australian users, who tend to value transparency and control over their data. Pairing the delivery strategy with a clear opt-in flow and a quiet-hours setting aligned to Australian Eastern Standard Time keeps complaint volumes low and engagement high.