One Link, One Address: The Engineering Behind Blinkit’s Address-Sharing Feature

Have you ever wanted to order something for a friend on Blinkit but had to ask them for their complete address, apartment number, landmark, and exact map location? Blinkit's address-sharing experience aims to eliminate much of this friction. What appears to be a simple product feature actually touches several interesting areas of software engineering: deep linking, backend APIs, geospatial systems, identity management, and data consistency.

Although Blinkit has published engineering articles about its geospatial infrastructure, its exact internal implementation of address sharing is not publicly documented. This article explores how such a feature could work architecturally, using established engineering patterns rather than assuming access to Blinkit's proprietary implementation.

1. The First Building Block: Deep Linking

The foundation of a link-based sharing experience is deep linking. Instead of opening an application's homepage, a deep link directs a user to a particular screen or resource within the application.

When someone initiates an address-sharing request, the backend can create a unique sharing request and return a URL associated with it. The recipient opens the link through a messaging application, and the operating system routes it to the relevant screen in the installed app, where supported. If the app is unavailable, a web fallback can handle the request.

This is supported by technologies such as Android App Links and Apple Universal Links.

The important design decision is that the link should identify the sharing request rather than expose the complete address directly. The backend can resolve that identifier and determine what actions the recipient is permitted to perform.

2. The Backend: Managing the Sharing Workflow

Behind the interface, a backend service can manage the lifecycle of an address-sharing request. It creates the request, associates it with the initiating user, generates a secure link, and tracks whether the recipient has responded.

When the recipient opens the link, the application retrieves the relevant request details. The recipient can then select or confirm the intended delivery location. Once submitted, the backend validates the request and coordinates the address transfer or import.

A useful architectural distinction is between the sharing service and the address service. The former manages the request, permissions, and expiration; the latter manages the actual address record. Separating these responsibilities avoids duplicating address-management logic and makes the system easier to maintain.

The backend must also handle retries, expired links, and duplicate submissions. For example, opening or submitting the same link twice should not unintentionally create duplicate saved addresses.

3. Why a Delivery Address Is More Than Text

A delivery address is not simply a string containing a building name and locality. A reliable representation may include a formatted address, latitude and longitude, a building or apartment identifier, and specific delivery instructions.

This is where geospatial systems become important. Geocoding converts an address into geographic coordinates, while reverse geocoding converts coordinates into a readable address. Google's Geocoding API documentation explains both operations.

However, accurate coordinates do not automatically guarantee accurate delivery. A map pin might point to the centre of an apartment complex rather than its entrance. Human-readable details, landmarks, and delivery instructions may still be essential.

Blinkit's engineering article, The GIS Journey at Blinkit, discusses the company's broader geospatial infrastructure and geographic service boundaries. Its earlier article, The Journey of Your Order from the Warehouse to Your Doorstep, also discusses geocoding and delivery logistics.

These resources illustrate why location accuracy is an operational concern, not merely a user-interface detail.

4. Serviceability, Security, and Reliability

Once a location has been selected, the platform may need to determine whether it falls within an eligible delivery area. This can involve geographic service boundaries, nearby fulfilment locations, and additional operational constraints. A valid address is not necessarily a serviceable one.

Security presents another challenge. A shared link can potentially be forwarded to unintended recipients, so a production implementation should use unpredictable tokens, expiration, revocation, and server-side authorization. Sensitive address information should not be unnecessarily exposed in URLs or logs, and the recipient should explicitly confirm the location before it is imported.

Reliability matters just as much. The backend must prevent conflicting state changes if multiple requests arrive simultaneously, support safe retries when network failures occur, and preserve the correct relationship between the sharing request and the intended user account.

These considerations demonstrate how a small feature can involve distributed-systems concepts such as idempotency, transactional consistency, and access control.

Conclusion

Blinkit's address-sharing experience is an interesting example of how thoughtful product design depends on several layers of engineering working together. Deep links connect users to the correct workflow, backend services coordinate the transfer, and geospatial systems help represent and validate the physical destination.

The broader lesson is that sharing a delivery address is not simply about transferring text between two people. It is about transferring structured, location-sensitive data reliably and securely while preserving the context required for a successful delivery.

The exact architecture Blinkit uses for this feature remains undocumented publicly, but its published GIS engineering article and delivery logistics article provide useful insight into the geospatial challenges surrounding it. Combined with established deep-linking and geocoding technologies, they offer a foundation for understanding how such a feature can be engineered at scale.