# Exploring a Different API Gateway Architecture for NGINX

**URL:** <https://community.nginx.org/t/exploring-a-different-api-gateway-architecture-for-nginx/9983>\
**Category:** Community Showcase\
**Tags:** module, reverse-proxy, web-server\
**Created:** [July 7, 2026, 2:07pm UTC](https://community.nginx.org/t/exploring-a-different-api-gateway-architecture-for-nginx/9983 "2026-07-07T14:07:10Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rootmese](https://drob5swvtjqxg.cloudfront.net/user_avatar/community.nginx.org/rootmese/32/4526_2.png) [@rootmese](https://community.nginx.org/u/rootmese)\
**Post date:** [July 7, 2026, 2:07pm UTC](https://community.nginx.org/t/exploring-a-different-api-gateway-architecture-for-nginx/9983/1 "2026-07-07T14:07:10Z")

</div>

I’d like to share a project I’ve been working on for a while and, more importantly, start a technical discussion about API Gateway architectures.

HTTP DMMR was born from a collection of old ideas that had been gathering dust in my Pastebin for years, eventually evolving alongside the technology itself. The original goal was to build a Layer 7 switch focused on mitigating DoS attacks. Time passed, cloud computing changed the way those problems are solved, but I realized that many of the architectural concepts behind that original idea were still worth exploring.

The result is an API Gateway implemented as a native NGINX module written in C, accompanied by an independent cache daemon.

I wanted to explore a different architectural approach based on three simple principles:

leverage as much as possible what NGINX already provides;  
minimize external dependencies whenever possible;  
keep the request path as short as possible.

Today we have API Gateways offering hundreds of features. That’s a perfectly valid approach and fits many use cases. My curiosity, however, was to explore the opposite direction: how far can we go with a simple, lightweight architecture written almost entirely in C?

The current version (0.0.2-alpha) already includes:

native NGINX module;  
API Key authentication;  
dynamic request routing;  
rate limiting;  
standalone cache daemon;  
lightweight binary protocol between the module and the daemon;  
Unix Domain Socket and TCP communication;  
Berkeley DB persistence.

The next step I’m most excited about is evolving the daemon into a distributed peer-to-peer cache with state synchronization between instances. In a world dominated by containers and distributed applications, I believe this kind of architecture still has plenty of room to evolve.

I might be completely wrong. That’s exactly why I’m making the project public and bringing it here for discussion.

The project is still in alpha and there’s a long road ahead. At this stage, what I’m looking for is feedback, criticism, and technical discussions with people who also enjoy distributed systems, NGINX 😍 , and C programming.

Project:

> **[GitHub - rootmese/http\_dmmr\_nginx: High-performance API Gateway module for Nginx...](https://github.com/rootmese/http_dmmr_nginx)**
>
> High-performance API Gateway module for Nginx written in C, featuring routing, authentication, rate limiting, plugin support and a binary cache protocol.

Best regards

Alessandro Silveira

---

<div class="post-metadata">

**Author:** ![buulam](https://drob5swvtjqxg.cloudfront.net/user_avatar/community.nginx.org/buulam/32/3733_2.png) [@buulam](https://community.nginx.org/u/buulam)\
**Post date:** [July 8, 2026, 12:56am UTC](https://community.nginx.org/t/exploring-a-different-api-gateway-architecture-for-nginx/9983/2 "2026-07-08T00:56:08Z")

</div>

Very interesting! Thanks for sharing @rootmese !

---

<div class="post-metadata">

**Author:** ![rootmese](https://drob5swvtjqxg.cloudfront.net/user_avatar/community.nginx.org/rootmese/32/4526_2.png) [@rootmese](https://community.nginx.org/u/rootmese)\
**Post date:** [July 8, 2026, 1:23am UTC](https://community.nginx.org/t/exploring-a-different-api-gateway-architecture-for-nginx/9983/3 "2026-07-08T01:23:45Z")

</div>

Thank you,

The project is still evolving, and I’m continuing to refine the architecture, testing, and documentation.

Suggestions and technical feedback are always welcome!