Loading…
Topic
Serverless
99 posts about Serverless. Every summary links to the original.
- 99 posts
- 13 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Because nobody likes being charged twice
Payment workflows can produce duplicate charges when a customer retries after a connection drop while the backend is still retrying the original request. The post frames network timeouts, crashes, database locks, downstream errors, and user interruptions as normal distributed-systems failures that can leave payment state uncertain. It recommends generating a unique idempotency key for one specific action, sending it with the Stripe request, and reusing it on every retry; Stripe recognizes the key for 24 hours and returns the original response. It also recommends placing payment jobs in a queue such as Amazon SQS, where workers retry failures and route repeatedly failing messages to a dead-letter queue. Together, queues preserve work during temporary outages and idempotency makes retries safe, while careful key scope and timing avoid stale or cross-operation behavior.
Using an AWS microservice architecture for subscription management
Enterprise subscription management must handle mid-cycle plan changes, usage-based billing adjustments, synchronized service updates, atomicity, failed operations, data consistency, and auditability beyond basic recurring billing. This sample architecture uses an event-driven AWS design in which subscription changes are published to EventBridge and routed to Step Functions workflows. EventBridge provides at-least-once delivery, content-based filtering, dead-letter queue support, and integration with Step Functions, while Lambda functions validate changes, calculate Stripe proration, update external subscriptions, and trigger service-specific actions. Step Functions supplies retries with exponential backoff for StripeTemporaryError, DynamoDB stores current and historical subscription data using transactional updates, and Stripe calls use an event identifier as an idempotency key. The pattern is presented as a flexible foundation for reliability, maintainability, compensation for partial changes, and auditability in systems handling financial transactions and service provisioning.
Real-time payment analytics: Building a data pipeline from Stripe to AWS
Payment processors such as Stripe emit numerous transaction events, while dashboard and API-based or batch approaches can limit historical analysis, real-time visibility, and correlation with business metrics as volumes grow. The proposed pipeline sends signed Stripe webhooks through API Gateway to Lambda for validation and enrichment, buffers them in Kinesis Data Streams, and uses a second Lambda to transform and index records in OpenSearch. OpenSearch Dashboards provides visualizations, while CloudWatch tracks pipeline health; Kinesis retention and replay support recovery and reprocessing. The post also describes a Kinesis Data Firehose route that can remove the consumer Lambda and reduce costs but may add batching latency. The resulting design is presented as scalable to millions of transactions per day, with sub-minute payment metrics visibility and flexible historical querying, while security guidance includes encryption, IAM configuration, and regular audits.
Load balancing Stripe API calls from multiple AWS regions
The guide describes a multi-region payment-processing architecture for applications that use Stripe’s API and need resilience against regional outages, latency, rate limits, and payment-data compliance constraints. It routes requests with Amazon Route 53 health checks and configurable latency-based, weighted, or geolocation policies, while identical regional API Gateway and Lambda deployments process payments. DynamoDB Global Tables replicate payment state and support distributed rate limiting, with optimistic locking, regional token-bucket allocation, retries, and exponential backoff for Stripe requests. The sample Lambda records a payment as PENDING, creates and confirms a Stripe PaymentIntent, then updates the state with the Stripe payment ID and returned status; the conclusion presents the design as a foundation for regional resilience, state consistency, and API-rate management.
Importing sales data from Stripe into AWS
The article presents a low-code method for analyzing Stripe business and customer data and moving scheduled report results into AWS. Stripe Sigma lets users query payment, subscription, and plan-related data with SQL, while Sigma Assistant can generate and execute queries from natural-language prompts such as cancellation analysis. For delivery, the article uses the sigma.scheduled_query_run.created event and Stripe's Event Destination to Amazon EventBridge, where a partner event bus and event rule trigger AWS services without a separate public webhook API. Its Lambda example downloads the report CSV with the Stripe API key, parses it into JavaScript objects, and publishes the result through Amazon SNS; the same event-driven pattern can support Lambda, Step Functions, or Glue workflows.
Building serverless usage notification with AWS
Pay-as-you-go services need a way to warn customers when consumption reaches a configured limit, but building usage aggregation, monitoring, and notification workflows adds operational complexity. This tutorial uses Stripe Billing Alerts to define a customer-specific usage threshold with a customer_id, meter_id, gte value, and recurrence, then sends billing.alert.triggered events through Stripe Event Destinations to an Amazon EventBridge partner event source. It tests the flow with Stripe Meter Events and shows AWS CLI rules routing the event to Amazon SNS, as well as a Lambda example that retrieves the customer's email from Stripe and sends mail with Amazon SES. The result is a minimal-code notification path using AWS services, with sandbox setup required because some APIs and features may not be available in conventional test mode.
Building resilient webhook handlers in AWS: Implementing DLQs for Stripe events
Reliable Stripe webhook processing must account for lost deliveries from network or service outages, out-of-order events, and duplicates caused by Stripe retries. The proposed AWS architecture uses API Gateway for signature validation and throttling, an SQS FIFO queue for ordered delivery and content-based deduplication, Lambda for processing, DynamoDB for event-ID idempotency, and an SQS DLQ for failed messages. In the CloudFormation example, the main queue has a 300-second visibility timeout and sends messages to the FIFO DLQ after three receives; DynamoDB records expire through a seven-day TTL. Lambda retries failures with exponential backoff, while CloudWatch monitors queue depth, latency, and errors. The design is presented as a scalable foundation, with multi-region failover available at added cost and complexity, though single-region deployment may suffice for many applications.
Developing a modern architecture for energy utilities with embedded finance
Energy utilities can use embedded finance to create marketplace-like experiences for tariffs, solar installations, smart-home devices, storage, and related services while capturing more energy-related revenue. The proposed foundation combines Stripe Online Payment Flows, Billing, Payments, Connect, and Data Pipeline with AWS serverless services, including Lambda, EventBridge, DynamoDB, Redshift, S3, and QuickSight. A tariff enrollment or payment can trigger webhooks and real-time event processing, while transaction and customer data support dashboards, usage insights, personalized recommendations, subscriptions, and broader partner offerings. The architecture also describes PCI Level 1 security, encryption, Radar, Strong Customer Authentication, AWS IAM, KMS, Shield, WAF, Config, Security Hub, and CloudWatch for compliance and monitoring. It concludes that this integrated payment, analytics, and security foundation can help utilities improve customer engagement, support sustainable programs, and develop new revenue streams.
How do I store inventory data in my Stripe application
The DevRel Swag Store uses Stripe payments and AWS services to keep product inventory accurate and visible in near real time. Stripe products retain core payment information, while Amazon DynamoDB stores inventory and other attributes, keyed by Stripe product ID and store ID; EventBridge routes payment events to Lambda, which atomically decrements stock and publishes updates through AWS IoT Core to the frontend. DynamoDB condition expressions prevent decrements when stock is insufficient, while post-payment validation and refunds address the delay before a Stripe Payment Link is disabled, although Stripe fees may be non-refundable. A custom Payment Intent flow can check stock before payment, authorize funds with manual capture for up to seven days, update inventory after payment success, and then capture the charge.
Data access patterns for simple Stripe integrations
The article examines how applications should store and access product data in simple Stripe integrations as requirements for security, performance, and scalability evolve. It compares using Stripe’s built-in product fields with a separate database, while explaining that publishable API keys cannot retrieve product details and that secret or restricted keys must remain server-side. A web backend or serverless function can proxy requests securely, while CloudFront caching reduces repeated calls and latency but requires an appropriate refresh cadence. For richer metadata, inventory, variants, or custom attributes, the article describes combining DynamoDB with Lambda and Stripe, using Event Destinations or webhooks to synchronize changes and weighing that flexibility against database overhead.
Growing your Stripe integration With Event Destinations
Stripe Event Destinations, now in general availability and rolling out to all accounts, lets companies extend payment workflows without changing existing integrations. The post explains how Stripe events can be sent either to an AWS account through Amazon EventBridge or to a webhook endpoint, with EventBridge routing selected events to services such as AWS Lambda, Step Functions, and SQS. Event filtering, logging, transformation, and built-in security reduce the need to operate webhook servers and verify signatures in application code. Serverless Lambda functions can add custom logic and connect to DynamoDB, S3, or SNS, supporting examples including date-limited memberships, partial student payments, and real-time tipping broadcasts through AWS IoT Core and WebSockets. The resulting architecture is presented as flexible and scalable for variable or growing event volumes while preserving the underlying Stripe integration.
Event Driven Machines
Event Driven Machines presents Lambdo, a pattern for using Fly Machines as short-lived, event-triggered compute rather than relying on HTTP activation. It polls an SQS queue for JSON events, batches the messages and metadata, then creates fast-booting Fly Machines with the events written to /tmp/events.json; the Machine is destroyed after processing finishes. Application code can come from an existing codebase or Lambdo’s Node and PHP runtime images, with handlers or commands processing each event. SQS message attributes select the required image and can specify VM size and command, while the approach supports arbitrary code and even GPU-enabled Machines, giving each event control over its execution environment.
Rethinking Serverless with FLAME
Rethinking Serverless with FLAME presents a pattern for running selected application functions on short-lived copies of the full app instead of moving code into bespoke FaaS services. FLAME, short for Fleeting Lambda Application for Modular Execution, uses FLAME.call to send a function and closed-over values to a runner pool, while retaining access to the application’s database connections and other code. The Elixir flame library includes LocalBackend and FlyBackend adapters, and Fly.io can boot a same-image Machine in the parent’s region in about three seconds. Runners may stay warm, scale to zero, or grow elastically based on configuration. The post also describes process-based streaming with LiveView and supervision and monitoring mechanisms for transient runners.
Building ChatGPT Plugins with Supabase Edge Runtime
A TypeScript template for ChatGPT Plugins runs on Supabase Edge Runtime and provides a path for exposing a TODO API to ChatGPT. The implementation serves the required ai-plugin.json manifest from an Edge Function because static file hosting is not currently supported, and generates an OpenAPI JSON document from endpoint JSDoc annotations with swagger-jsdoc. An Oak router defines TODO routes, while shared CORS headers allow requests from https://chat.openai.com and credentials. Docker configuration runs Edge Runtime locally with a bind-mounted functions directory, enabling changes without rebuilding and exposing requests through localhost:8000. The guide also covers local installation and testing through the ChatGPT UI, then deployment to Fly.io; it notes authentication as a possible next step.
Supabase Beta April 2023
Supabase’s April 2023 Beta Update reports on Launch Week 7 and a broad set of product, ecosystem, and community announcements. It open-sources Logflare as Supabase Logs, adds a self-hostable Edge Runtime for Deno Functions, and presents Storage v3’s resumable uploads for files up to 50GB, with quality filters, Next.js support, and WebP support. Auth additions include SAML 2.0 SSO, PKCE, Sign in with Apple for iOS, and server-side support, while Studio 2.0 brings redesigns, developer-experience improvements, and new AI features. The update also announces dbdev, a PostgreSQL package manager, Trusted Language Extensions for Postgres, pg_graphql v1.2, search using GitHub Discussions, API report improvements, and a storage permission change, while noting Page Assist as the hackathon winner and Firecrawl’s move from Pinecone to Supabase for PostgreSQL vector embeddings.
Supabase Edge Runtime: Self-hosted Deno Functions
Supabase has open-sourced Edge Runtime, an MIT-licensed Rust web server built on Deno Runtime 1.32+ for self-hosting Deno Edge Functions. It serves TypeScript, JavaScript, and WASM functions, and existing Supabase Edge Functions can run without code changes; the release also adds npm modules and Node built-in APIs. The Supabase CLI uses it to serve all local functions with JWT verification, import maps, custom environment variables, hot reload, and defaults of 150 MB memory and 60 seconds execution time. Its architecture combines hyper, a Main Worker in a V8 isolate, and restricted User Workers that handle requests with controllable resource limits, while exposing APIs intended to improve development and deployment parity. A Fly.io demonstration shows deployment, with Digital Ocean and AWS also cited as provider options; the project is in beta with bugs and performance quirks still expected.
Designing with AI: Generating unique artwork for every user
Supabase Launch Week 7 needed distinctive, shareable tickets that could improve on earlier Launch Week designs while keeping overlaid text readable. The team experimented with Midjourney prompts and blends, then chose minimalist purple swirls and a gold overlay approach after finding generated visuals too chaotic and direct gold prompting unreliable. For each ticket, a Supabase Edge Function retrieves a cached PNG from Supabase Storage or renders HTML and CSS into an SVG with Vercel’s Satori, layering backgrounds, a GitHub profile picture, and text before uploading the result with long cache control. A Postgres view selectively exposes ticket fields, calculates referral counts and marks a ticket golden when both Twitter and LinkedIn sharing have been detected, while row-level security protects the underlying email-containing table. Supabase Realtime then sends client-side updates so users can see progress and stop listening once golden.
Storing OpenAI embeddings in Postgres with pgvector
Post describes how embeddings represent semantic relatedness as vectors and how OpenAI’s text-embedding-ada-002 model produces 1536-dimensional embeddings for text. It addresses storing and searching large or dynamically changing collections that may not fit comfortably in memory, using PostgreSQL and the pgvector extension instead of a small CSV-and-NumPy workflow. The implementation enables the vector extension, creates a documents table with a vector(1536) column, and defines match_documents() with cosine distance, thresholds, counts, and ordering. It also shows JavaScript code for generating embeddings, a search flow that retrieves matching documents for prompt context, and token limiting before a completion request, while noting that documents can be chunked. For larger tables, the post recommends an ivfflat index with vector_cosine_ops and gives 4 * sqrt(table_rows) as a starting point for lists.
Supabase Beta December 2022
Supabase's December 2022 beta update recaps Launch Week 6, Community Day, Postgres ecosystem work, and other recent releases. The announcements include redesigned documentation rebuilt with Next.js; Storage v2 features for image resizing, webhooks, and a Smart CDN; and multi-factor authentication with optional enforcement through Row Level Security. Supabase Wrappers extend PostgreSQL Foreign Data Wrappers to query external databases, systems, and third-party APIs using SQL, while The Vault enters beta for encrypted secrets and stored data. The update also announces custom domains, point-in-time recovery, SSO on the dashboard in preparation for SAML, and ecosystem projects including pg_graphql v1.0, a PostgREST 11 pre-release, and an experimental pg_crdt extension.
Launch Week 6 Hackathon Winners
Supabase announced the winners of its sixth hackathon, held during Launch Week 6 after ending 2022 with many feature releases. Projects were judged across categories including Best Overall, Most Fun/Interesting, Best Flutter, Best Storage, and Best Edge Functions, with Deno participating in judging the edge category. Depulso, a CLI and web app for static site deployments with per-deployment .depulso.site subdomains and SSL, won Best Overall, while Supa SQL App was runner-up for converting human language into SQL queries. Other winners included HTTP Sense, a reverse proxy and network monitoring tool; supaquiz, a realtime multiplayer trivia game; Lookout, a metadata-based image discovery app; and Vista, a video transcoder that adds customizable subtitles from audio. Winners received keyboards or swag, and a Discord event was scheduled for January 5 at 7:00 AM PST.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.