Create a Serverless REST API with Route Hit Counter

By Pulumi Team
Published
Updated

The Challenge

You need a serverless API that tracks usage metrics for different routes. This pattern is useful for monitoring API usage, understanding which endpoints are most popular, building lightweight analytics, or learning how Lambda, API Gateway, and DynamoDB work together.

What You'll Build

  • API Gateway REST API with catch-all routing
  • Lambda function with appropriate IAM permissions
  • DynamoDB table for storing route visit counts
  • Automatic counter incrementing on each request
  • JSON response with route name and current count

Neo Try This Prompt in Pulumi Neo

Run this prompt in Neo to deploy your infrastructure, or edit it to customize.

Best For

Use this prompt when you need to track API usage patterns, build lightweight endpoint analytics, or learn how serverless components connect on AWS. Also useful as a foundation for rate limiting, A/B testing, or any application that needs per-route counters.

Architecture Overview

This architecture connects three core AWS serverless services into a request-counting pipeline. API Gateway receives HTTP requests and routes them to a Lambda function, which reads and updates a counter in DynamoDB before returning the result. Because all three services are serverless, the system scales to zero when idle and handles traffic spikes without provisioning.

The API Gateway uses a catch-all (greedy) path parameter, meaning every route you hit goes to the same Lambda function. The function extracts the path from the request, uses it as the DynamoDB key, and atomically increments the counter. This atomic increment is important because DynamoDB handles concurrent updates correctly, so you get accurate counts even under load.

This is a good learning architecture because it exercises the fundamental serverless building blocks (compute, storage, API routing, IAM) in a simple, observable way. You can hit the API, see the counter go up, and trace exactly how data flows through the system. It is also a useful foundation for more complex patterns like rate limiting or usage-based billing.

API Gateway

API Gateway provides the HTTP endpoint that clients call. The catch-all route configuration means you do not need to define individual routes. Every request, regardless of path, gets forwarded to the Lambda function with the full request context including the path.

Lambda Function

The Lambda function is the compute layer. It receives the API Gateway event, extracts the route path, performs an atomic update-and-read operation on DynamoDB, and returns a JSON response. IAM policies grant the function read and write access to the DynamoDB table.

DynamoDB Table

DynamoDB stores the counters as key-value pairs where the key is the route path and the value is the access count. The atomic increment operation (UpdateItem with ADD) ensures accurate counts even when multiple requests hit the same route simultaneously. DynamoDB’s single-digit-millisecond latency keeps the overall response time low.

Common Customizations

  • Add timestamps: Extend the Lambda function to record the last access time alongside the count, useful for identifying stale routes.
  • Separate read and write endpoints: Add a dedicated GET endpoint that returns all route counts without incrementing, giving you a dashboard-friendly read path.
  • Add rate limiting: Use the counter values to enforce per-route rate limits, rejecting requests once a threshold is reached within a time window.
  • Switch to on-demand capacity: Ask for DynamoDB on-demand pricing mode instead of provisioned capacity if your traffic is unpredictable.