Understanding Digital Public Infrastructures (DPIs)
One Level Deep
#3 in a series of 29 on Africa’s EdTech Breakthrough System & Project.
Executive Summary
A Digital Public Infrastructure (DPI) is a shared, society-scale digital system that provides non-rival digital capabilities through open specifications, interoperable components, and public-interest governance.
This essay distinguishes first-generation, single-country DPIs (e.g., Estonia, India) from modern, multi-country DPIs, which must explicitly separate what can be shared globally from what must vary locally. Without this separation, reuse across borders collapses.
Using Android as an architectural analogy, the essay explains the thick-core / thin-adapter pattern that enables scale while preserving sovereignty. Network effects in DPIs multiply when improvements in one country benefit all others using the same infrastructure.
Africa’s DPI for Education (DPI-Ed) is among the first serious attempts to design a DPI explicitly for multi-country use from the outset.
This essay provides the architectural foundation needed to understand how Africa’s DPI-Ed—and RESPECT—can scale continent-wide.
Why One Level Deep?
Most explanations of Digital Public Infrastructure (DPI) stay intentionally high-level. They describe what a DPI does, not what it is, why it evolved the way it did, or what architectural principles distinguish single-country infrastructure from multi-country infrastructure.
That level of abstraction is fine for awareness-building; it is insufficient for leaders who must adopt, govern, fund, regulate, or build DPIs.
They need one additional level of conceptual clarity.
This essay provides that extra level.
1. What is a DPI?
A Digital Public Infrastructure (DPI) is a shared, society-scale digital system—defined by open specifications, interoperable components, and public-interest governance—that provides non-rival digital capabilities which many independent public and private actors can use to deliver, scale, and innovate services for the public good.
A non-rival digital capability is a digital function that many independent users can use at the same time without reducing anyone else’s ability to use it.
The Internet is a familiar example of both a non-rival digital capability and a DPI. All modern DPIs are built atop the Internet. Likewise, the Linux operating system is free and open source software controlled by a non-for-profit foundation in the public interest. Linux powers everything from Android phones to cloud servers.
In practice, the term DPI is most often used to describe government-enabled digital infrastructure that supports both public and private services. Identity services, access to public records, and payment systems are common examples.
A useful analogy is a public road: it is a non-digital public infrastructure on which public buses and private cars can both operate.
2. Before “DPI”
Before India introduced the term Digital Public Infrastructure (DPI) around 2021, national digital ecosystems went by many names:
- Estonia: e-government, e-services, X-Road
- India: IndiaStack, Digital India
- Kenya: eCitizen
- Multilaterals: platforms, digital rails, digital enablers
After its 2021 introduction, the DPI name was quickly adopted by the UN, World Bank, ITU, GovStack, AUDA-NEPAD, and others.
For clarity, this essay refers to the national systems created before this period as first-generation DPIs, even though they predate the “DPI” term.
Estonia and India created DPI stacks that offered many services, with ID, Data Exchange, and Payments being the foundation on which other up-stack services were built.
3. First-Generation DPIs: Single-country
Estonia and India built the world’s most influential first-generation DPI stacks. Their architectures were groundbreaking—but they were fundamentally single-country systems.
They shared many characteristics:
- Deep coupling to national law and regulation
- Dependence on country-specific trust institutions
- Documentation primarily in prose
- Behavior defined largely by running code
- Tight coupling between implementation and specification
This made them excellent digital systems within their home countries—but any country attempting to reuse Estonia’s or India’s implementation would be forced to inherit their:
- Compliance logic
- Institutional roles
- Data-governance assumptions
- Regulatory preconditions
- Trust model
Few sovereign countries would consider sacrificing their sovereignty in this way, although individual components from India’s IndiaStack (notably UPI) and Estonia’s e-government (notably X-Road) have been adopted in a few countries.
Thus, first-generation DPI stacks succeeded within single countries but struggled to scale across borders.
4. Network Effects in DPI
Network effects in DPIs emerge when improvements in one part of the DPIs ecosystem benefit every other part. These network effects produce large public value within a single country, as has been amply demonstrated by the first-generation, single-country DPIs.
When multiple countries share the same DPI, then the DPI’s ecosystem expands accordingly. Every improvement, integration, and developer skill acquired in one country is immediately reusable in other countries, too. This multi-country use of the same DPI magnifies that DPI’s network effects enormously, thus increasing its public value enormously as well.
5. The Android Model
Android—though not a DPI—is a global free and open source digital infrastructure with which most readers of this essay will be familiar. Its architecture offers a powerful lesson for modern DPIs.
Android’s architecture
Android’s architecture separates what can be shared globally from what must vary locally:
- Shared globally: The Android Open Source Project (AOSP)—the core code used by billions (based on the Linux operating system)
- Varies locally through static resources (not code):
- Localization
- Hardware Adapters
- Carrier & Regulator Adapters
- Service-provider Adapters
This architecture has (mostly) avoided fragmentation: every Android device worldwide runs substantially the same core code.
Lesson for multi-country DPIs
Decades of operating-system engineering—from Unix and POSIX to Windows NT, Linux, to Android—converged on a common architecture: stable, globally-shared core code with well-defined interfaces for everything that must vary locally. Android is simply a familiar embodiment of that architecture.
Today, multi-country DPIs and DPI stacks are becoming operating systems for government services. As such, they should follow the same Android-like model:
- One shared implementation of core code (global, FOSS, collaboratively maintained).
- A localization layer for country-specific rules, workflows, terminology, and user interfaces.
- A service-provider adapter layer for integrations with banks, telcos, ID authorities, registries, and regulators.
- Machine-testable specifications so that local adaptations remain interoperable with the global core.
This is described in this essay series as the thick-core, thin-adapter model.
This architecture cleanly separates what can be shared globally (core code, APIs, protocols) from what must remain sovereign (laws, institutional roles, national workflows), with the latter implemented as sovereign/service adapters. Countries do not need to rewrite the core; they tailor only the adapters in which the variation is encapsulated.
The results are significant: dramatically lower implementation cost, faster deployment, simpler maintenance, easier cross-country reuse, and vastly stronger network effects—all of which translate into higher public value.
This same architectural separation—shared core code, sovereign/service adapters—is now emerging across second-generation DPIs. Section 6 examines how closely today’s leading building blocks follow this pattern
6. Second-Generation DPI Stacks: Specifications and Implementations
If DPIs are “operating systems for government services,” as claimed in the previous section, then their evolution depends on two layers working together:
- A specification layer that defines what each service’s building blocks must do and how blocks interact.
- An implementation layer of code through which the specifications are executed.
GovStack: The Global Specification Layer
GovStack is the most mature, widely accepted specification framework for DPIs today. It defines:
- the required functions of each building block,
- the APIs they must expose,
- the workflows they must support, and
- a reference sandbox for verifying interoperability.
GovStack deliberately avoids prescribing any vendor or implementation. Countries, vendors, or open-source communities remain free to build their own components—so long as they conform to the shared specifications. This creates the conditions for modularity, substitutability, and global network effects. It has emerged as the de facto standard interface definition layer for DPIs.
The Implementation Layer: How Close Are Today’s DPIs to the Android-like Architecture?
Table 1 (below) evaluates major open-source DPI building blocks against the “Android-like” thick-core, thin-adapter architectural pattern described in Section 5, without endorsement.
What This Table Shows
1. A clear convergence toward the Android-like pattern
MOSIP and the newer versions of X-Road show the most mature separation between a thick core and thin sovereign/service adapters. OpenG2P and Inji are moving in that direction, though still forming deployment norms. Others show value but lack the architecture needed for shared global reuse.
2. Less Android-like = more fragmentation
Where country-specific variation requires modifying the core itself–thinning the core and thickening the adapters—deployments fork, ecosystems fragment, and network effects remain small. This increases costs and slows innovation.
3. GovStack provides the stabilizer
GovStack’s specification layer gives countries and implementers a common contract to converge around—even when multiple implementations exist. This enables competition without fragmentation, and interoperability without vendor lock-in.
Table 1: DPI Implementation Landscape (as observed in current deployments and roadmaps as of late 2025)
| DPI / Component | Shared Core Implementation | Explicit Localization / Adapter Layer | Fragmentation Risk / Deployment Variability | Comments |
|---|---|---|---|---|
| MOSIP (ID) | High — Single upstream “kernel” intended for many countries; microservice-based; governed by IIIT-B; deployments (Morocco, Ethiopia, Philippines, etc.) use the same core. https://docs.mosip.io/platform/architecture | High — Policy/config modules, reference adaptors, well-documented integration points for country systems. | Medium–Low — Architecture encourages config-first variation; some risk of custom forks as deployments grow. | Very close to the Android-like ideal for ID. |
| X-Road (Data Exchange) | High — Same core release used across Estonia, Finland, Iceland, and others; national deployments configure security policy, not core code. https://docs.x-road.global/Architecture | Medium–High — Strong system-parameter model and security/policy configuration; adapters live mostly in connected systems. | Medium — Different national variants exist, but remain recognisably X-Road; divergence risk manageable with governance. | More Android-like than many realise; “sovereignty at the edges” mostly via policy and configuration. |
| OpenG2P (G2P) | Medium–High — Shared reference platform; core services for identity resolution and payment orchestration are common; local workflows vary. https://docs.openg2p.org | Medium–High — Variation designed to live in configurable rules, workflows, and integrations to payments / ID stacks. | Medium — Could become very Android-like if governance stays strong; risk of each G2P programme becoming bespoke. | Architecturally promising; lived practice will determine its eventual F-score. |
| Inji (Wallet) | Medium — Wallet core is shared; the connector layer is designed for multi-DPI compatibility but is still evolving across deployments. https://docs.inji.io | Medium — Connector/adaptor concept is explicit, but patterns are not yet “locked in” across many countries. | Medium–High — Early pilots are at risk of becoming snowflakes if not steered toward shared upstream. | Could become the Android-like wallet layer, but needs strong contribution and governance norms. |
Implications for Future DPI Initiatives
For any new DPI—whether national, regional, or sector-specific—the guiding principles are now clear:
- Use GovStack to specify each building block and its interoperations with other building blocks.
- Build implementations using an Android-like architecture: one shared global thick core, with thin sovereign/service adapters at the edges.
- Govern the localizations nationally, and the shared core globally.
This model is increasingly visible across second-generation DPIs. It is also the model most likely to unlock the full network effects—and global public benefit—of Digital Public Infrastructure.
7. Where the Android-like Model Doesn’t Work
GovStack started as an attempt to generalize Estonia’s eGovernment system across all of the European Union. Most EU countries already have digital systems for Identity, Data Exchange, and Payments. These systems are, by and large, already entrenched; the economic, social, and political cost of replacing them with an EU-wide standard implementation was, and is, too high to justify the costs. That is, GovStack faces a post-entrenchment service landscape.
Instead of attempting to replace the EU members states’ entrenched digital services with a single thick-core, thin adapter suite of building blocks, GovStack takes a different tack: It provides merely the specification layer for a service’s building blocks, with the expectation that those services will “wrap” each EU member’s entrenched services with a common, shared specification layer, thereby enabling interoperability among the services. This “thin-core, thick-adapter” model is a practical response to the post-entrenchment service landscape of the EU member states.
However, where entrenched digital services are mostly absent—for example, in many Low Income Countries—a thick-core, thin-adapter DPI model is more appropriate, due to its increased network effects and hence increased public value.
8. Caveats
None of this is inevitable. Adopting DPIs requires a shift in capability. Governments cannot simply buy a license and walk away; they (or their integrators) must actively manage the ‘localization layer.’ Without strong local governance, even open-source DPI stacks can create dependency on the technical vendors managing localization and service-provider adapters.
In addition, countries must maintain continuous compliance with global specifications. GovStack evolves, and so do GovStack-compatible building blocks. Without active local capability to validate, version, and govern updates, a country can unintentionally fall out of compliance or drift into fragmentation.
To meet these new demands, countries should consider developing, within their country’s ICT Ministries, a DPI governance function, responsible for versioning, compliance testing, localization management, and integration oversight.
Some low-resource countries may turn to global cloud vendors (Amazon, Microsoft, & Google) to provide this function. This risks enabling these vendors’ historical Embrace, Extend, and Extinguish behavior. We must be cautious.
9. Conclusion
As someone faced with making decisions about DPIs, you now understand DPIs—one level deep.
- You now understand that the world is rapidly moving beyond first-generation, single-country DPIs and DPI stacks to second-generation, multi-country DPIs and DPI stacks.
- You now understand that you need to choose and/or build robust, globally-sharable, easily-localizable implementations of each DPI building block that have been validated against GovStack’s specifications.
The era of buying ‘black box’ solutions is over. Decision-makers must now require vendors to demonstrate how their solutions comply with GovStack specs and utilize global open-source building blocks like MOSIP, ensuring that the country—not the vendor!—owns the localization.
We now have the understanding, the architecture, and the opportunity to build Digital Public Infrastructure that delivers public value at global scale.
Let’s get to work!
Trademarks: All trademarks mentioned—including IndiaStack, MOSIP, Inji, OpenG2P, X-Road, and UPI—are the property of their respective owners.
The next essay in this series is 04. Understanding Africa’s DPI Experience.
