The origin: borrowing from evolutionary computing

The term comes from genetic algorithm design. In evolutionary computing, a fitness function defines what "better" means so that solutions can gradually emerge through small changes across generations. The classic example: when using a genetic algorithm to optimise wing design, the fitness function assesses wind resistance, weight, air flow, and other desirable characteristics. At each generation, the engineer asks: is this closer to or further away from the goal?

Ford, Parsons and Kua borrow this concept for software:

An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).

In software, fitness functions check that developers preserve important architectural characteristics; the "-ilities" architects care about: scalability, security, performance, maintainability, resilience.

The core idea

An evolutionary architecture supports guided, incremental change across multiple dimensions. The key word is guided. Without guidance, incremental change is just drift. Fitness functions are what provide the guidance.

The fitness function protects the various architectural characteristics required for the system. These requirements differ greatly across systems and organisations: some require intense security; others require significant throughput or low latency; others need resilience to failure. A crucial early architecture decision is to define which dimensions matter most for a given system, based on business drivers, technical capabilities, and scale.

Why this matters

Most teams have implicit architectural goals: "the system should be fast", "services should be loosely coupled", "we should be secure". The problem is that implicit goals erode. Nobody notices the slow degradation until a characteristic has already failed.

Fitness functions make the implicit explicit. They turn architectural aspirations into verifiable checks. Automated where possible, manual where necessary.

A key insight: improving one architectural dimension can accidentally harm another. Improving performance with caching might harm data freshness or security. Fitness functions act as guardrails that detect these tradeoff violations before they reach production.

Categorising fitness functions

The book defines several dimensions for classifying fitness functions:

Atomic vs Holistic

• Atomic — tests one particular aspect of the architecture in isolation. Example: a unit test checking for cyclic dependencies in a package, or a code metric that checks cyclomatic complexity.
• Holistic — tests a combination of architectural aspects, assessing interactions between different concerns. Example: testing the number of concurrent users within a certain latency range while caching is enabled — this simultaneously checks scalability and data freshness. Holistic functions are harder to build but capture what atomic ones miss.

Triggered vs Continuous vs Temporal

• Triggered — executed in response to a specific event: a developer running a unit test, a CI pipeline stage, a QA person performing exploratory testing.
• Continuous — constant verification of architectural aspects. Monitoring and alerting are the classic examples. Netflix's Chaos Monkey — which runs in production and randomly terminates instances — is a continuous holistic fitness function that forces teams to build resilient services.
• Temporal — have a particular time component. Example: a reminder to check whether important security updates have been performed, or a scheduled dependency check that alerts on outdated libraries.

Static vs Dynamic

• Static — fixed predefined acceptable values. Binary pass/fail (a unit test), or a threshold (latency must be < 200ms).
• Dynamic — acceptable values depend on context. Acceptable latency might depend on actual system scale; security requirements might vary based on the regulatory environment.

Automated vs Manual

• Automated — unit tests, deployment pipeline checks, stress tests, chaos engineering. Ideally as much automation as possible.
• Manual — some things can't be automated (legal approval requirements, certain QA processes). Some things aren't automated yet. The goal is to push the boundary toward automation over time.

What fitness functions look like in practice

Fitness functions encompass existing engineering practices but also extend beyond them:

The best fitness functions are automated and triggered: they give feedback at the point of change, not weeks later. Place them in the deployment pipeline. Fast atomic functions early, slow holistic functions later.

Deployment pipelines as the enforcement mechanism

Fitness functions only work if they're part of the delivery workflow. The deployment pipeline is where they live:

1. Early stages — fast, atomic checks: architecture tests (phpat, ts-arch), code metrics, linting, security scanning, contract tests.
2. Middle stages — integration and performance tests, holistic triggered functions.
3. Later stages / production — continuous monitoring, chaos engineering, temporal reminders.

As Thoughtworks puts it: "creating the desired fitness functions — and including them in appropriate delivery pipelines — communicates these metrics as an important aspect of enterprise architecture."

The four layers of fitness (from NILUS)

A useful framing from practice splits fitness functions across four layers:

1. Structural fitness — code dependencies, database access patterns, API contracts, service boundaries.
2. Behavioural fitness — latency, resilience, throughput, consistency, recovery behaviour.
3. Operational fitness — deployment independence, observability coverage, runbook readiness, SLO compliance.
4. Semantic fitness — bounded context integrity, event naming quality, policy ownership, domain model consistency.

Most teams start at structural (the easiest to automate) and never reach semantic. But semantic fitness functions (checking that your domain model remains coherent as it evolves) are often the most valuable for long-lived systems.

Systems thinking

Dr. Russell Ackoff's quote captures the deeper point:

A system is never the sum of its parts. It is the product of the interaction of its parts.

Fitness functions that only measure individual components miss the point. The interesting failures happen at integration boundaries — between services, between teams, between intentions and reality. Holistic fitness functions (end-to-end latency, deployment frequency, change failure rate) capture what atomic ones cannot.

How I'm applying this

This connects directly to work I care about:

• Platform modernisations I've designed and implemented were operational fitness: bringing reliability through automated deployment pipelines, observability and monitoring, and runbook readiness. I just called it "keeping things running."
• ADRs capture the decisions. Fitness functions verify those decisions are still holding. Decisions and verification go hand in hand.
• Kent Beck's Test Desiderata is itself a fitness function for test quality — a checklist of characteristics that tests should exhibit (isolated, deterministic, fast, behavioural, structure-insensitive, specific, predictive).
• DORA metrics (deployment frequency, lead time, change failure rate, MTTR) are fitness functions for delivery capability.
• Code health metrics (as described in the Loveholidays case from Tropeçando 120) are fitness functions that enabled their AI-first shift — they invested in code health metrics before adopting AI, which is exactly the fitness-function-first approach.
• phpat (PHP, as a PHPStan extension) and ts-arch (TypeScript) — writing architecture rules as unit tests that run in CI is the purest implementation of triggered atomic fitness functions.

The pattern: define what matters, measure it, enforce it automatically, and revisit periodically. Architecture that can't be verified can't evolve — it can only decay.

Further reading

• Foreword to Building Evolutionary Architectures — Martin Fowler's foreword to the book, framing fitness functions as the mechanism to monitor architectural state in an evolutionary style.
• Fitness function-driven development — Paula Paul & Rosemary Wang apply the TDD mindset to architecture: write the fitness function first, then develop to pass it.
• Governing data products using fitness functions — Extending fitness functions into Data Mesh governance (2024).
• Building Evolutionary Architectures, 2nd Edition — The book.

Part of my reading notes on Building Evolutionary Architectures (Ford, Parsons, Kua).

Chapter 1: Software Architecture

Despite our best efforts, software becomes harder to change over time. For a variety of reasons, the parts that comprise software systems defy easy modifications, becoming more brittle and intractable over time. Changes in software projects are usually driven by a reevaluation of functionality and/or scope. But another type of change occurs outside the control of architects and long-term planners. Though architects like to be able to strategically plan for the future, the constantly changing software development ecosystem makes that difficult. Since we can't avoid change, we need to exploit it.

— On Evolutionary Architecture

An evolutionary architecture supports guided, incremental changes across multiple dimensions.

— Definition of Evolutionary Architecture

Related: Ralph Johnson on Architecture (via Fowler, 2003)

These quotes from Ralph Johnson (from [[2026-04-24 - Martin Fowler - Who Needs an Architect|Who Needs an Architect?]]) are foundational to the ideas in this book:

"In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called 'architecture.' [...] the architecture only includes the components and interfaces that are understood by all the developers."

— Architecture as a social construct, not a diagram.

"There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don't know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication."

— The fundamental tension that evolutionary architectures try to navigate: change vs complexity.

"Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. 'We have met the enemy, and he is us.'"

— The constraint is us, not the technology.

Chapter 2: Fitness Functions

An evolutionary architecture supports guided, incremental change across multiple dimensions.

-- on FItness Functions, chapter 2

The fitness function protects the various archutectural characteristics required for the system. The specific architectural requirements differ greatly across systems and organizations, based on business drivers, technical capabilities, and a host of other factors. Some systems require intense security; others require significant throughput factors.

-- on Fitness Functions, chapter 2

A system is never the sum of its parts. It is the product of the interaction of its parts.

-- Dr. Russel Ackoff

The Foreman Problem: Managing Teams When Your Best Worker Isn't Human - Willian Correa

Every major technology shift invented a new management role. Steam power → foreman. Office computing → project manager. Internet → product manager. AI is doing the same, but this time the failure mode is invisible: confident, polished, wrong output. The new job is not directing effort but verifying that things that look like they're running actually are.

Who Will Be the Senior Engineers of 2035? - James Stanier

The traditional junior-to-senior pipeline is breaking: entry-level tech postings down 67% since 2022, junior employment down ~20%. Firms adopting AI saw junior employment fall 7.7% vs non-adopters. 54% of engineering leaders plan to hire fewer juniors.

Compound Engineering & Code Health

The Compounding Software Factory - Luca Rossi (Software Factory series, Part 3 of 3)

What causes teams to degrade: poor coding hygiene (bad testing, poor code health, missing abstractions), failure to capture knowledge (no ADRs, no playbooks, no snapshots), and building the wrong things.

AI Coding Meets Code Health - Stuart Caborn

Loveholidays' journey to becoming an AI-first engineering organization. Core thesis: code health is the foundation for successful AI adoption. By deliberately investing in code health metrics before adopting AI, they achieved 80+ deployments/month, 60% AI-written code, <1% change failure rate, all while maintaining elite code health.

Security & Infrastructure

The (In)security Landscape of AI-Powered GitHub Actions - Shay Berkovich

AI-powered GitHub Actions from vendors like OpenAI, Anthropic, and Google are now running in thousands of public workflows. Research found bypasses of non-default configurations letting any external attacker trigger AI execution, a novel secret exfiltration vector for dynamically-created credential files, and widespread misconfigurations in production workflows.

The Invisible Engineering Behind Lambda's Network - Werner Vogels

A decade-long story of invisible infrastructure engineering by Lambda's networking team.

Career & Token Economics

Tokenmaxxing Is the Budget Game Played With AI Tokens - Willian Correa

Tokenmaxxing — maximising AI token consumption for visibility — is the corporate "use it or lose it" budget game in a new currency. Meta's internal "Claudeonomics" leaderboard ranked 85K employees by token consumption; top user burned 281B tokens in 30 days.

Tools

Use Compose Watch

Docker bind volumes gets a supercharge. Compose Watch does not replace bind mounts but exists as a companion specifically suited to developing in containers.

More importantly, watch allows for greater granularity than is practical with a bind mount. Watch rules let you ignore specific files or entire directories within the watched tree.
For example, in a Node.js project, it's not recommended to sync the node_modules/ directory. Even though JavaScript is interpreted, npm packages can contain native code that is not portable across platforms.

A "geek" is someone who is highly creative, highly technical, and highly attached to being both.

-- GeePaw Hill

Check https://rafael.bernard-araujo.com/refactoring-patterns/introduce-parameter-object

There are PHP and Rust implemenation examples.

Luca Rossi argues that the right measure of AI effectiveness isn't lines of code but leverage — how much output you get per unit of human input. Teams progress through three stages: writing full specs for everything, then encoding knowledge into shared rules (like AGENTS.md), and finally building reusable modules that enforce correctness by design.

The security case for serverless just got stronger

AI agents can now scan an entire open-source codebase for exploitable vulnerabilities in hours.

Frontier models carry the complete library of known bug classes in their weights. So you can simply point an AI agent at a codebase and tell it to find zero-days.

This isn't theoretical.

Yan Cui highlights that AI agents can now find real zero-days in open-source codebases at scale, shrinking the patch window from weeks to hours. Serverless and managed services have a structural advantage because AWS patches the runtime for you. The practical takeaways: eliminate long-lived AWS keys everywhere, treat LLM API keys like credentials, and scan your repos for exposed secrets.

Do not use secrets in environment variables and here's how to do it better

Every Layer of Review Makes You 10x Slower

Each approval layer adds 10x wall clock time, and AI can't fix that. It only speeds up the first step. Drawing on Deming and the Toyota Production System, the argument is that review layers hide root causes rather than fixing them. The memorable line: "The job of a code reviewer isn't to review code — it's to figure out how to obsolete their review comment, that whole class of comment, forever."

The common thread across all four: the bottleneck isn't writing code, it's the systems around it. Whether it's review layers, security patching, or AI leverage, the answer is the same: engineer quality into the system itself through tests, automation, modules, and clear interfaces, rather than adding layers of inspection after the fact.

Claude Code cache chaos creates quota complaints

Anthropic changed the prompt cache TTL from 1 hour to 5 minutes in March. Long, high-context sessions hit quota limits much faster. Pro users report as few as 2 prompts per 5 hours. Leaving your machine for >1 hour = full cache miss on the 1M token context. They're considering reducing the default to 400K tokens.

Token consumption matters more than ever. The next two tools address this from both ends.

Caveman — Output Token Compression

Constrains LLM output to minimal-token structures. Strips pleasantries and padding, keeps code and technical content. Up to 87% output token reduction. Paper shows brevity constraints improve accuracy by 26pp.

RTK (Rust Token Killer) — Input Token Compression

Intercepts shell command outputs (git, ls, grep, test runners, docker, AWS CLI — 100+ commands) and compresses them before they reach the LLM context. 60-90% input token reduction, < 10ms overhead.

Works with: Claude Code, Copilot, Gemini CLI, Codex, Cursor, Windsurf, Cline.

Why do multi-agent coding systems fall apart on complex, real-world tasks?

How to Manage Context in AI Coding

Focus on building multiplayer, dynamic systems that provide the right information reliably, rather than crafting magical wording. Design workflows where AI can fetch what it needs automatically.

Value Object

When programming, I often find it's useful to represent things as a compound.

Range - Further Enterprise Application Architecture development

It's quite common to see comparisons where a value is checked against a range of values. Ranges are usually handled by a pair of values and you check against them both. Range instead uses a single object to represent the range as a whole, and then provides the relevant operations to test to see if values fall in the range and to compare ranges.

JDK 17 Memory Bloat in Containers: A Post-Mortem

I just love runtime upgrades. Runtime upgrade are very important. And they need careful planning. Not unusual that they teach us important lessons for the next upgrade.

When engineering teams modernize Java applications, the shift from JDK 8 to newer Long-Term Support (LTS) versions, such as JDK 11, 17, and soon 21, might seem straightforward at first. Since Java maintains backward compatibility, it's easy to assume that the runtime behavior will remain largely unchanged. However, that's far from reality.

My Fitbit Buzzed and I Understood Enshittification

My Fitbit started buzzing at me a year ago. “It looks like you’re exercising.”

Product development is also an exercise in human relationships. And when we reduce those relationships to metrics, we lose something essential. We lose the ability to say, “This would be rude.” We lose the ability to treat users like people instead of engagement vectors.

Using the Middleware Pattern to Extend PHP Libraries

PSR-15 did not invent middleware. But it showed the PHP community what a well-designed, typed middleware interface looks like. There is no reason to leave that idea at the HTTP layer.

If you maintain a PHP library with any non-trivial processing, consider building middleware support in from day one. Your users will thank you, and so will your future self.

Serverless apps are fantastic for automatic scaling, but there’s a catch: they expect you to be stateless. Most web applications, however, rely on sessions to remember users and persist state. Traditional PHP session handlers store data on the filesystem, which doesn’t play nicely with ephemeral AWS Lambda instances. Your sessions vanish as soon as the instance disappears.

The usual fix? Fire up a Redis cluster. Works, but suddenly you’ve added infrastructure, ongoing maintenance, and extra costs. Your “serverless” app feels a lot less serverless.

What if we could manage sessions without touching Redis or any other server?

In this post, we’ll show you how to build a truly serverless PHP app using Bref, Symfony, and DynamoDB for session management. Along the way, you’ll see:

• A custom DynamoDB-backed session handler that replaces filesystem sessions
• How to deploy your app via Lambda Function URLs using AWS CDK
• Storing CSRF tokens in DynamoDB for fully stateless operation
• Single-table design patterns for efficient multi-entity storage

By the end, you’ll know not just how to implement this architecture, but also when it makes sense and what trade-offs you’re accepting.

The Challenge: Sessions in Serverless

Before we dive into the solution, let’s understand why traditional PHP sessions fail in serverless environments.

1. Ephemeral Storage: Lambda instances can vanish at any time. Writing sessions to /tmp is like storing them in sand. They disappear when the instance is recycled.
2. No Shared Filesystem: Each Lambda invocation runs on its own instance. User A’s session written by instance 1 is invisible to instance 2. That’s a problem if your user expects to stay logged in.
3. Horizontal Scaling Woes: Lambda scales horizontally automatically. Without centralized session storage, each instance is isolated. Consistent session management? Forget it.

The Traditional Solution: Redis/ElastiCache

Most serverless PHP guides suggest Redis. While it works, it comes with headaches:

• Infrastructure complexity: VPCs, subnets, and security groups
• Maintenance burden: Patching, monitoring, capacity planning
• Cold start penalty: VPC-connected Lambdas can take 1–2 extra seconds

Better idea: DynamoDB. It’s fully managed, serverless, and scales automatically. No Redis cluster, no maintenance, just pay for what you use.

Books and Authors App (Serverless Style)

Imagine you’re building a multi-tenant SaaS app, like an internal tool for managing books and authors. Each user needs a session, and each organization manages its own data. DynamoDB’s single-table design can elegantly handle all this. Serverless scaling takes care of traffic spikes automatically.

Here’s what this example demonstrates:

• Multi-entity relationships: Books belong to authors
• CRUD operations: Create, read, update, and delete across related entities
• Session-dependent workflows: Adding/editing books requires authentication
• Real-world complexity: More than a simple counter, less than a full e-commerce platform

Connecting to Real Use Cases

This architecture shines in scenarios like:

• Unpredictable traffic: Seasonal spikes when authors release new books
• Session management: Authors need persistent sessions to edit content
• Cost efficiency: During quiet periods, you pay pennies; during spikes, DynamoDB scales automatically
• Zero maintenance: No Redis clusters to monitor, no database servers to patch

The book management example proves that this approach isn’t just theoretical: it’s production-ready.

Architecture Overview

To build a serverless PHP application that supports sessions, CSRF protection, and persistent data, we follow a stateful/stateless separation pattern. This makes the architecture scalable, cost-efficient, and easy to maintain.

1. Stateful Layer: Persistent Data

This layer is responsible for storing all data that needs to survive beyond a single Lambda invocation.

• DynamoDB Table

  • Uses a single-table design to store sessions, CSRF tokens, users, books, and authors.
  • TTL enabled for automatic session expiration.
  • On-demand billing ensures automatic scaling with traffic.
  • Built-in multi-AZ replication provides high availability.

• Benefits

  • No infrastructure to manage or patch.
  • Automatically scales with unpredictable traffic.
  • Centralized storage simplifies queries and operations.

2. Stateless Layer: Application Logic

This layer runs the application code and handles requests without storing any persistent state locally.

• Lambda Function

  • Runs PHP-FPM via Bref.
  • Handles HTTP requests directly using a Lambda Function URL (HTTPS endpoint).
  • No VPC required to access DynamoDB, reducing cold start latency.

• Static Assets

  • Stored in S3 (optionally served via CloudFront) to keep Lambda stateless.

• Benefits

  • Scales automatically with traffic.
  • Cost-efficient: pay only for actual requests.
  • Stateless logic simplifies deployment and updates.

This design ensures a truly serverless PHP application that handles session state, persistent data, and scalable workloads without the operational overhead of managing Redis or other caching layers.

DynamoDB Session Handler and CSRF Implementation

Session Handler Implementation

In a serverless PHP application, traditional session storage (files or local memory) doesn’t work because Lambda functions are ephemeral. Each invocation may run on a different container, so we need a centralized, persistent session store.

The core of our solution is a custom session handler that implements PHP's SessionHandlerInterface.

How It Works

• Sessions are stored in DynamoDB instead of the filesystem.
• Each session has a unique session_id, which becomes the partition key (PK) in DynamoDB.
• Sessions include the serialized PHP session data and an expiration timestamp (TTL).
• The handler automatically reads/writes session data on session_start() and session_write_close().

Key Features

1. Automatic Expiration
   • DynamoDB TTL ensures sessions are removed automatically after expiration.
2. Atomic Operations
   • PutItem and UpdateItem guarantee consistent writes, even with concurrent requests.
3. Scalable
   • Can handle thousands of concurrent sessions without extra infrastructure.
4. Serverless-friendly
   • No local storage, no Redis, fully compatible with Lambda statelessness.

Implementation

<?php

namespace App\Session;

use AsyncAws\DynamoDb\DynamoDbClient;
use AsyncAws\DynamoDb\Input\DeleteItemInput;
use AsyncAws\DynamoDb\Input\GetItemInput;
use AsyncAws\DynamoDb\Input\PutItemInput;
use AsyncAws\DynamoDb\ValueObject\AttributeValue;

/**
 * A minimal DynamoDB-backed PHP session handler using AsyncAws.
 *
 * Table design (single-table compatible):
 *  - PK: "SESSION"
 *  - SK: "SID#<session_id>"
 *  - data: base64-encoded session payload (string)
 *  - expiresAt: unix epoch seconds (number), enable DynamoDB TTL on this attribute
 *
 * Garbage collection is handled by DynamoDB's TTL, so gc() is a no-op.
 */
class DynamoDbSessionHandler implements \SessionHandlerInterface
{
    private const string PK_VALUE = 'SESSION';
    private const string SK_PREFIX = 'SID#';

    public function __construct(
        private readonly DynamoDbClient $dynamoDb,
        private readonly string $tableName,
        private readonly int $ttlSeconds = 3600,
    ) {}

    public function open(string $path, string $name): bool
    {
        // Nothing to do
        return true;
    }

    public function close(): bool
    {
        // Nothing to do
        return true;
    }

    public function read(string $id): string
    {
        $result = $this->dynamoDb->getItem(new GetItemInput([
            'TableName' => $this->tableName,
            'Key' => [
                'PK' => new AttributeValue(['S' => self::PK_VALUE]),
                'SK' => new AttributeValue(['S' => self::SK_PREFIX . $id]),
            ],
            // Strongly consistent read to reduce stale sessions
            'ConsistentRead' => true,
        ]));

        $item = $result->getItem();
        if (!$item || !isset($item['data'])) {
            return '';
        }

        $encoded = $item['data']->getS();
        if ($encoded === null) {
            return '';
        }

        $payload = base64_decode($encoded, true);
        return $payload === false ? '' : $payload;
    }

    public function write(string $id, string $data): bool
    {
        $expiresAt = time() + $this->ttlSeconds;

        $this->dynamoDb->putItem(new PutItemInput([
            'TableName' => $this->tableName,
            'Item' => [
                'PK' => new AttributeValue(['S' => self::PK_VALUE]),
                'SK' => new AttributeValue(['S' => self::SK_PREFIX . $id]),
                'data' => new AttributeValue(['S' => base64_encode($data)]),
                'expiresAt' => new AttributeValue(['N' => (string) $expiresAt]),
            ],
        ]));

        return true;
    }

    public function destroy(string $id): bool
    {
        $this->dynamoDb->deleteItem(new DeleteItemInput([
            'TableName' => $this->tableName,
            'Key' => [
                'PK' => new AttributeValue(['S' => self::PK_VALUE]),
                'SK' => new AttributeValue(['S' => self::SK_PREFIX . $id]),
            ],
        ]));

        return true;
    }

    public function gc(int $max_lifetime): int|false
    {
        // Rely on DynamoDB TTL to expire items; nothing to scan/delete here.
        return 0;
    }
}

Why it matters?

This approach:

• Keeps your PHP sessions serverless-compatible.
• Avoids cold-start pitfalls associated with local or in-memory session storage.
• Provides a reliable, scalable, and fully managed solution for stateful data in a stateless environment.

CSRF Token Storage

In a serverless environment, CSRF tokens must be handled carefully. Because Lambda executions are stateless, tokens cannot be stored in memory or on the filesystem. Instead, CSRF tokens are persisted in DynamoDB alongside session data.

This approach ensures tokens remain valid and verifiable across multiple Lambda invocations.

How CSRF Tokens Are Stored

Each CSRF token is stored as a dedicated item in the DynamoDB table:

• Tokens are associated with a specific action
• Each token has a unique identifier
• An expiration timestamp is stored for automatic cleanup

This makes CSRF token storage consistent, durable, and serverless-compatible.

Data Model

CSRF tokens follow the same single-table design pattern used elsewhere in the application.

Using a distinct partition key avoids contention and allows tokens to scale independently from session traffic.

Lifecycle

1. A CSRF token is generated when a form is rendered.
2. The token is persisted in DynamoDB.
3. On form submission, the token is retrieved and validated.
4. After validation or expiration, the token is deleted or allowed to expire via TTL.

This lifecycle mirrors traditional CSRF handling while remaining compatible with Lambda’s

Implementation

class DynamoDbCsrfTokenStorage implements CsrfTokenStorageInterface
{
    private const string PK_VALUE = 'CSRF';
    private const string SK_PREFIX = 'TOKEN#';

    public function getToken(string $tokenId): string
    {
        $result = $this->dynamoDb->getItem(new GetItemInput([
            'TableName' => $this->tableName,
            'Key' => [
                'PK' => new AttributeValue(['S' => self::PK_VALUE]),
                'SK' => new AttributeValue(['S' => self::SK_PREFIX . $tokenId]),
            ],
        ]));

        $item = $result->getItem();
        return $item['value']->getS() ?? '';
    }

    public function setToken(string $tokenId, string $token): void
    {
        $expiresAt = time() + $this->ttlSeconds;

        $this->dynamoDb->putItem(new PutItemInput([
            'TableName' => $this->tableName,
            'Item' => [
                'PK' => new AttributeValue(['S' => self::PK_VALUE]),
                'SK' => new AttributeValue(['S' => self::SK_PREFIX . $tokenId]),
                'value' => new AttributeValue(['S' => $token]),
                'expiresAt' => new AttributeValue(['N' => (string) $expiresAt]),
            ],
        ]));
    }
}

This ensures CSRF protection works seamlessly across multiple Lambda invocations.

Symfony Configuration

Configuring Symfony correctly is key for serverless PHP apps to work reliably with Lambda, DynamoDB, and Bref. Here’s how we set it up.

1. Session Storage

We replace the default PHP session handler with our DynamoDBSessionHandler:

# config/packages/framework.yaml
framework:
    session:
        handler_id: App\Session\DynamoDBSessionHandler
        cookie_secure: auto
        cookie_samesite: lax
        cookie_lifetime: 3600  # 1 hour

Notes:

• handler_id points to our custom service.
• cookie_secure: auto ensures HTTPS enforcement on Lambda URLs or custom domains.
• cookie_lifetime aligns with DynamoDB TTL for consistency.

2. Service definition

Register the DynamoDB session handler as a Symfony service:

# config/services.yaml
services:
  App\Session\DynamoDbSessionHandler:
    arguments:
      $tableName: '%book_table_name%'
      $ttlSeconds: '%env(default:session_ttl_seconds:int:SESSION_TTL)%'

• $tableName comes from environment variables to support multiple environments.
• $ttl matches the session lifetime for automatic garbage collection.
  This configuration tells Symfony to use our custom handler for all session operations. The handler is automatically injected with the DynamoDB client through Symfony's autowiring.

3. RequestContextListener

To handle dynamic Lambda Function URLs, we register a listener:

# config/services.yaml
services:
    App\EventListener\RequestContextListener:
        tags:
            - { name: kernel.event_listener, event: kernel.request, method: onKernelRequest }

Purpose:

• Ensures Symfony’s URL generator produces correct URLs.
• Sets proper scheme and host for redirects, forms, and CSRF validation.
• Essential for Lambda Function URLs where host/scheme changes per invocation.

Why It’s Needed

Lambda Function URLs:

• Provide a direct HTTPS endpoint (e.g., https://xyz.lambda-url.us-east-1.on.aws/)
• Are dynamic and unknown at build time
• Require Symfony to know the scheme and host at runtime to generate correct URLs

Without a listener:

• Redirects may point to HTTP instead of HTTPS
• CSRF tokens may fail
• Session cookies might be rejected
• OAuth or SSO integrations could break

Implementation

<?php

namespace App\EventListener;

use Symfony\Component\EventDispatcher\Attribute\AsEventListener;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\HttpKernel\KernelEvents;
use Symfony\Component\Routing\RequestContext;

#[AsEventListener(event: KernelEvents::REQUEST, priority: 1024)]
class RequestContextListener
{
    public function __construct(private RequestContext $requestContext) {}

    public function onKernelRequest(RequestEvent $event): void
    {
        if (!$event->isMainRequest()) {
            return;
        }

        $request = $event->getRequest();

        // Force HTTPS for Lambda URLs and set proper context
        if ($request->headers->get('host') && str_contains($request->headers->get('host'), 'lambda-url')) {
            $this->requestContext->setScheme('https');
            $this->requestContext->setHost($request->headers->get('host'));
            $this->requestContext->setHttpPort(80);
            $this->requestContext->setHttpsPort(443);

            $request->server->set('HTTPS', 'on');
            $request->server->set('SERVER_PORT', 443);
            $request->server->set('REQUEST_SCHEME', 'https');
        }
    }
}

The CDK Output Dilemma:

// CDK can output the Lambda URL after deployment
new CfnOutput(this, 'LambdaURL', { 
    value: statelessStack.monolithLambdaFunctionUrl.url 
});
// But this value is only known AFTER deployment completes
// You can't use it as an environment variable in the SAME deployment

Tip: This listener is only necessary if you use the Lambda Function URL as the production endpoint. If you use a custom domain, this can be simplified or skipped.

With this configuration, Symfony becomes serverless-ready, maintaining sessions, CSRF protection, and routing behavior seamlessly while leveraging DynamoDB and Lambda.

Single-Table Design Pattern

All entities (sessions, CSRF tokens, users, books, authors) live in a single DynamoDB table. This simplifies the architecture and enables atomic operations across different entities.

• Why single-table?
  • Reduces infrastructure complexity.
  • Simplifies monitoring and backup.
  • Supports atomic transactions across multiple entity types.
  • Aligns with AWS best practices for DynamoDB.

AWS CDK Infrastructure with Bref

Deploying a serverless Symfony app requires some AWS setup. Using AWS CDK with Bref makes this smooth, maintainable, and repeatable.

Why CDK?

• Infrastructure as code: Everything is versioned and reproducible.
• Integration with Symfony: Easy to link environment variables, DynamoDB, and Lambda functions.
• Bref-friendly: Deploy PHP Lambda layers without manually configuring Lambda functions.

Stateful Stack: DynamoDB Table

import { NestedStack } from "aws-cdk-lib";
import * as ddb from "aws-cdk-lib/aws-dynamodb";

export class BlogAppStatefulStack extends NestedStack {
  public readonly ddb: ddb.Table;

  constructor(scope: Construct, id: string, props: MyNestedStackProps) {
    super(scope, id, props);

    this.ddb = new ddb.Table(this, 'ddb', {
      tableName: `${id}-table`,
      partitionKey: { name: 'PK', type: ddb.AttributeType.STRING },
      sortKey: { name: 'SK', type: ddb.AttributeType.STRING },
      billingMode: ddb.BillingMode.PAY_PER_REQUEST,
      deletionProtection: props.shared.environment === 'prod',
      timeToLiveAttribute: 'expiresAt',
    });
  }
}

Key features:

• Generic Key Schema: PK and SK enable single-table design
• TTL Enabled: expiresAt attribute automatically removes expired items
• Production Protection: Deletion protection enabled for production environments

Stateless Stack: Lambda Function with Bref

import { packagePhpCode, PhpFpmFunction } from "@bref.sh/constructs";
import * as lambda from "aws-cdk-lib/aws-lambda";
import { FunctionUrl } from "aws-cdk-lib/aws-lambda";

export class BlogAppStatelessStack extends NestedStack {
  public readonly monolithLambda: PhpFpmFunction;
  public monolithLambdaFunctionUrl: FunctionUrl;

  private createLambda(props: MyNestedStackProps, staticAssetsBucket: Bucket, ddb: ddb.Table) {
    const lambdaEnvironment = {
      APP_ENV: props.shared.environment,
      APP_SECRET: appSecret,
      ASSET_URL: `https://${staticAssetsBucket.bucketDomainName}/`,
      AWS_LAMBDA_LOG_FORMAT: 'text',
      BOOK_TABLE_NAME: `${props.shared.stackPrefix}-StatefulStack-table`,
    };

    const monolithLambda = new PhpFpmFunction(this, 'App', {
      handler: 'public/index.php',
      phpVersion: '8.4',
      code: packagePhpCode('php', {
        exclude: ['.env.local', 'bin/'],
      }),
      functionName: `${props.shared.stackPrefix}-App`,
      timeout: Duration.seconds(28),
      memorySize: Size.gibibytes(2).toMebibytes(),
      environment: lambdaEnvironment,
    });

    // Create Function URL with no authentication
    const monolithLambdaFunctionUrl = monolithLambda.addFunctionUrl({ 
      authType: lambda.FunctionUrlAuthType.NONE 
    });

    // Grant DynamoDB permissions
    ddb.grantReadWriteData(monolithLambda);

    return { monolithLambda, monolithLambdaFunctionUrl };
  }
}

Lambda Function URL Configuration

Lambda Function URLs provide a simple HTTPS endpoint without needing API Gateway:

const monolithLambdaFunctionUrl = monolithLambda.addFunctionUrl({ 
  authType: lambda.FunctionUrlAuthType.NONE 
});

Benefits of Lambda URLs:

• Simplicity: Direct HTTPS endpoint without API Gateway complexity
• Cost: No API Gateway charges
• Performance: One less hop in the request path
• Built-in HTTPS: Automatic TLS certificate management

Configuration Options:

• authType: NONE: Public access (suitable for web applications)
• authType: AWS_IAM: Requires AWS signature (for service-to-service communication)

Main Stack: Orchestration

export class BlogApp extends Stack {
  constructor(scope: Construct, id: string, props: MyStackProps) {
    super(scope, id, props);

    const stackPrefix = props.shared.envStackPrefix;

    const statefulStack = new BlogAppStatefulStack(
      this, `${stackPrefix}-StatefulStack`, props
    );

    const statelessStack = new BlogAppStatelessStack(
      this, `${stackPrefix}-StatelessStack`, props, statefulStack
    );

    // Output important values
    new CfnOutput(this, 'Lambda', { 
      value: statelessStack.monolithLambda.functionName 
    });
    new CfnOutput(this, 'LambdaURL', { 
      value: statelessStack.monolithLambdaFunctionUrl.url 
    });
    new CfnOutput(this, 'DynamoDb', { 
      value: statefulStack.ddb.tableName 
    });
  }
}

Deployment with CDK

With the infrastructure defined, deploying the application becomes a repeatable and predictable process. This section focuses on how the application is built, deployed, and updated using AWS CDK.

Local Development Environment

Local development mirrors the production setup as closely as possible while remaining lightweight.

• Docker is used to provide a consistent PHP environment.
• A Makefile abstracts common commands to reduce cognitive load.
• Symfony runs locally with the same session and configuration logic used in Lambda.

You can run:

# Pre-requisite - source your aws profile
make up

You can check logs via make logs. And get into the container with make bash. The application will be available at http://localhost:8000, but it might fail to load as there is no existent DynamoDB to connect with. You can check local .env file for environment variables.

Deploying

Deploy the application using standard CDK commands (inside the container):

# Pre-requisite - Bootstrap CDK if this is your first deployment - npx cdk bootstrap aws://<ACCOUNT_ID>/<REGION>
# Install dependencies
npm run deploy

Alternatively, you can use the Makefile command outsite the container:

make deploy

What Gets Created

The deployment creates:

1. DynamoDB table with TTL enabled
2. Lambda function with PHP 8.4 runtime (via Bref)
3. Lambda Function URL for HTTPS access
4. S3 bucket for static assets
5. IAM roles and permissions

The output should be similar to:

BlogApp (sandbox-blog-app): deploying... [1/1]
sandbox-blog-app: creating CloudFormation changeset...

 ✅  BlogApp (sandbox-blog-app)

✨  Deployment time: 148.76s

Outputs:
BlogApp.AssetsBucket = sandbox-blog-app-sandboxbloga-assetsbucket5cb76180-5lu45xsqvuym
BlogApp.DynamoDb = sandbox-BlogApp-StatefulStack-table
BlogApp.Lambda = sandbox-BlogApp-App
BlogApp.LambdaURL = https://kiv7utcwku6gihqgs4bfkeuzma0oaylo.lambda-url.us-east-1.on.aws/
Stack ARN:
arn:aws:cloudformation:us-east-1:973974862728:stack/sandbox-blog-app/9ba92580-e50b-11f0-a602-0afffb8dc1a9

✨  Total time: 163.03s

In this case, https://kiv7utcwku6gihqgs4bfkeuzma0oaylo.lambda-url.us-east-1.on.aws/ is the Lambda public URL.

When you access the URL, you will see a log-in form. You can use the "Register" link to create a login. Use it and you will be able to manage Authors and Books. Try to log out and access the pages directly.

Internally it will execute a series of commands:

# clean
npm run clean && \
# execute php packaging including composer install and npm build for symfony
npm run package:sandbox && \ 
# deploy as a sandbox not requiring approval
NODE_ENV=sandbox cdk deploy --require-approval never

There is a prod version executing make deploy:prod.

Testing the Session Implementation

The application includes a test endpoint to verify session persistence:

#[Route('/session-test', name: 'session_test')]
public function test(Request $request): JsonResponse
{
    $session = $request->getSession();
    $counter = $session->get('counter', 0);
    $session->set('counter', $counter + 1);

    return new JsonResponse([
        'message' => 'Session test',
        'session_id' => $session->getId(),
        'counter' => $session->get('counter'),
        'handler' => get_class($session->getMetadataBag()->getMetadata('handler')),
    ]);
}

Test with curl:

# First request creates session
curl -i -c cookie.txt https://your-lambda-url/session-test

# Subsequent requests increment counter
curl -i -b cookie.txt https://your-lambda-url/session-test
curl -i -b cookie.txt https://your-lambda-url/session-test

# outputs
➜ curl -i -c cookie.txt https://your-lambda-url/session-test
{"message":"Session incremented","session_id":"02b0c08e1ccd5f3ea015a06c69e29d11","counter":1,"handler":"App\\Session\\DynamoDbSessionHandler"}%

➜ curl -i -b cookie.txt https://your-lambda-url/session-test
{"message":"Session incremented","session_id":"02b0c08e1ccd5f3ea015a06c69e29d11","counter":2,"handler":"App\\Session\\DynamoDbSessionHandler"}%

➜ curl -i -b cookie.txt https://your-lambda-url/session-test
{"message":"Session incremented","session_id":"02b0c08e1ccd5f3ea015a06c69e29d11","counter":3,"handler":"App\\Session\\DynamoDbSessionHandler"}%

Performance Considerations

Cold Start Optimization

1. Memory Allocation: Using 2GB memory reduces cold start times
2. Composer Optimization: --no-dev --optimize-autoloader reduces code size
3. PHP 8.4: Latest PHP version with JIT compiler support

DynamoDB Performance

1. Consistent Reads: Ensures session consistency at the cost of slightly higher latency
2. On-Demand Billing: No capacity planning, automatic scaling
3. TTL: Automatic cleanup without scan operations

The serverless model's primary advantage is alignment of costs with actual usage, particularly beneficial for applications with variable or unpredictable traffic patterns. However, actual costs vary significantly based on traffic patterns, request complexity, and specific use cases. It's recommended to use AWS cost estimation tools and monitor actual usage to understand the financial impact for your specific application.

Security Best Practices

Session Security

1. Secure Flag: Ensures cookies only sent over HTTPS
2. SameSite: Protects against CSRF attacks
3. Regenerate ID: After authentication to prevent session fixation

framework:
    session:
        cookie_httponly: true
        cookie_secure: auto
        cookie_samesite: lax

DynamoDB Permissions

The Lambda function requires minimal permissions:

ddb.grantReadWriteData(monolithLambda);

This grants only:

• dynamodb:GetItem
• dynamodb:PutItem
• dynamodb:DeleteItem
• dynamodb:Query
• dynamodb:Scan

No administrative permissions are granted to the Lambda function.

Limitations

While serverless PHP with DynamoDB sessions offers compelling advantages, it's important to understand the limitations and trade-offs. Here's an honest assessment of where this architecture may not be the best fit:

1. Cold Start Latency

The Reality: Lambda cold starts can add 1-3 seconds to the first request after a function has been idle. In practice this occurs for less than 1% of the calls.

Mitigation Strategies:

• Provisioned Concurrency: Pre-warm Lambda instances to eliminate cold starts (adds ~$15/month per instance)
• Keep-Warm Pings: Use CloudWatch Events to invoke functions every 5-10 minutes (adds minimal cost but doesn't help with scaling)
• Larger Memory Allocation: We use 2GB memory which provides faster CPUs, reducing cold start duration
• Optimize Code: Minimize dependencies, use PHP preloading, optimize autoloader

When it's acceptable: Background jobs, internal tools, APIs with relaxed SLAs
When it's problematic: User-facing e-commerce, real-time chat, gaming applications

2. Request Timeout Constraints

The Reality: Our configuration uses 28 seconds timeout (API Gateway compatible), though Lambda supports up to 15 minutes, which Lambda URLs supports.

Not Suitable For:

• Long-running batch jobs: Data exports, report generation, video processing
• Large file uploads: Direct file uploads over 10MB become unreliable
• Complex data migrations: Multi-step transformations requiring minutes to complete
• WebSocket connections: Not supported by Lambda Function URLs (use API Gateway WebSocket instead)

Recommended Alternatives:

• Keep Lambda URL: If API Gateway specific features are not needed, we can use custom domain with Lambda URLs and process up to 15 minutes
• AWS Step Functions: Orchestrate long-running workflows across multiple Lambda invocations
• ECS/Fargate: For truly long-running processes (hours), use containers instead
• Presigned S3 URLs: For large file uploads, let clients upload directly to S3
• SQS + Background Workers: Offload heavy processing to asynchronous queues

3. Session Consistency Edge Cases

The Reality: DynamoDB is eventually consistent by default, but we use ConsistentRead: true to mitigate this.

Why We Use ConsistentRead:

'ConsistentRead' => true,  // Ensures we always get the latest session data

Rare Race Conditions:
Even with consistent reads, race conditions can occur when:

• Simultaneous Writes: User opens multiple tabs, both modify session simultaneously—last write wins
• Write-then-Read Timing: Session written in one Lambda, immediately read by another—minimal delay possible
• Cross-Region Scenarios: If using Global Tables, replication lag can cause stale reads in remote regions

Practical Impact: In 99.9% of cases, consistent reads solve the problem. Edge cases typically affect power users opening many tabs or distributed teams across continents.

Mitigation: For critical operations (e.g., payment processing), use DynamoDB conditional expressions to ensure atomic updates and detect conflicts.

4. DynamoDB Costs at Scale

DynamoDB's pay-per-request pricing is cost-effective at low-to-moderate traffic but pricing characteristics change at high scale.

Assumptions

DynamoDB:

• On-demand billing: $1.25 per million reads/writes
• 1KB session item size
• 1 read + 1 write per request

Redis (ElastiCache):

• t4g.medium: $0.037/hr (~$27/month)
• 1 node sufficient for low-medium traffic
• High traffic may require bigger node(s)

Cost Table

When Fixed Infrastructure (like Redis/ElastiCache) May Become More Cost-Effective:

• Sustained high traffic volumes where fixed costs are fully utilized
• Long-lived sessions with more reads than writes
• Advanced caching features needed beyond simple session storage

Hidden DynamoDB Cost Factors:

• Consistent reads cost more than eventually consistent reads
• Session writes on every request (even if session data unchanged)
• AWS free tier limitations after 12 months

Start with DynamoDB for simplicity and operational efficiency. Monitor costs monthly as traffic grows. If costs become a concern at high scale, evaluate whether fixed infrastructure or caching optimizations make sense for your specific use case.

These limitations are not dealbreakers but they're trade-offs. For the right use cases (bursty traffic, cost-sensitive, minimal ops), the benefits far outweigh the drawbacks.

Conclusion

Building serverless PHP applications doesn't require sacrificing familiar frameworks or patterns. By implementing a custom DynamoDB session handler, we achieve:

• Truly serverless architecture: No Redis, no EFS, pure AWS managed services
• Production-ready session management: Consistent, scalable, and secure
• Cost-effective: Pay only for actual usage
• Developer-friendly: Standard Symfony application with minimal modifications
• Type-safe infrastructure: AWS CDK with TypeScript
• Modern PHP: PHP 8.4 with all latest features
• Local development: Docker-compose for local testing

The combination of Bref for Lambda PHP support, Symfony for application framework, and DynamoDB for stateful storage creates a robust, scalable, and maintainable serverless application architecture.

When Should You Use This Architecture?

Choose this approach when:

• Traffic is unpredictable or bursty (blogs, seasonal apps, internal tools)
• Cost optimization matters more than absolute performance
• Zero operational overhead is a priority
• You need automatic scaling without capacity planning

Common use cases are:

• CMS - Blogs, documentation sites, and knowledge bases with infrequent or sporadic traffic, when sudden spikes are scaled automatically and quite periods costs pennies
• Admin Panels and Internal Tools - Dashboard interfaces, internal reporting tools, and back-office applications with sporadic usage patterns. DynamoDB maintains session state without requiring Redis or similar infrastructure.
• Multi-Tenant SaaS Applications - B2B platforms where each tenant has independent traffic patterns. DynamoDB's single-table design efficiently manages sessions across all tenants without cross-tenant interference.
• API Services with Session Requirements - REST APIs that need stateful operations like OAuth flows, multi-step workflows, or temporary data caching. No Redis clusters to maintain, no session cleanup cron jobs to manage. DynamoDB TTL handles everything automatically.
• Seasonal Applications - Event registration systems, holiday campaign sites, tax filing applications, and other time-bound services.
• Microservices Requiring Session State - Distributed systems where individual services need temporary state management across invocations.

Consider alternatives when:

• You require consistent sub-100ms response times
• Traffic is predictable and sustained at high levels (>10M requests/month)
• Long-running processes or WebSocket connections are needed

The Bigger Picture

This implementation demonstrates that serverless and stateful aren't mutually exclusive. While serverless advocates often emphasize "stateless functions," real-world applications need state management. The key is choosing the right state storage mechanism, and DynamoDB proves that managed, serverless databases can handle session management as effectively as traditional infrastructure, with far less operational burden.

Whether you're building a content management system, an internal admin panel, or a multi-tenant SaaS application, this architecture provides a production-ready foundation. Start simple, monitor costs and performance, and scale confidently knowing your infrastructure will grow with your application without requiring a dedicated ops team.

Resources

• Bref Documentation
• Bref CDK Constructs
• AsyncAws DynamoDB Client
• Symfony Session Documentation
• Lambda Function URLs
• DynamoDB Single-Table Design

Source Code

The complete source code for this application is available at: rafaelbernard/serverless-php-with-bref-symfony-and-dynamodb-session-management/

For detailed technical implementation notes, test coverage reports, and deployment validation, see IMPLEMENTATION_SUMMARY.md in the repository. This document covers:

• Complete test suite (112 tests across PHP and CDK)
• Infrastructure validation details
• Code quality metrics
• Deployment procedures and best practices

Bonus: Guide to Custom Domain Configuration with Route53

Lambda Function URLs provide a quick way to expose your Lambda function over HTTPS, but the auto-generated URL (e.g., https://abc123xyz.lambda-url.us-east-1.on.aws/) isn't branded or memorable. But you can add a Simple CNAME Mapping: Direct Route53 CNAME to Lambda Function URL (easiest, limited SSL control).

This is the quickest and easiest method. Just create a CNAME record pointing to your Lambda Function URL. Best for internal tools, prototypes, and non-production environments.

Prerequisites

Before configuring custom domains, ensure you have:

1. Domain registered in Route53 (or another registrar with ability to update nameservers)
2. Hosted Zone created in Route53 for your domain

Implementation with CDK

Here's how to add a custom domain CNAME record pointing to your Lambda Function URL using AWS CDK:

import * as route53 from 'aws-cdk-lib/aws-route53';
import * as route53Targets from 'aws-cdk-lib/aws-route53-targets';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Construct } from 'constructs';

// Assuming you have a Lambda function with Function URL enabled
const myFunction = new lambda.Function(this, 'MyFunction', {
  // ... function configuration
  functionUrlOptions: {
    authType: lambda.FunctionUrlAuthType.NONE, // or AWS_IAM
  },
});

// Get the hosted zone for your domain
const hostedZone = route53.HostedZone.fromLookup(this, 'HostedZone', {
  domainName: 'yourdomain.com',
});

// Create CNAME record pointing to Lambda URL
new route53.CnameRecord(this, 'LambdaUrlCname', {
  zone: hostedZone,
  recordName: 'api', // Creates api.yourdomain.com
  domainName: cdk.Fn.parseDomainName(myFunction.functionUrl), // Extracts hostname from URL
  ttl: cdk.Duration.minutes(5),
  comment: 'CNAME to Lambda Function URL',
});

// Output the custom domain
new cdk.CfnOutput(this, 'CustomDomainUrl', {
  value: `https://api.yourdomain.com`,
  description: 'Custom domain URL for Lambda function',
});

Testing Your CNAME Setup

After creating the CNAME record, verify it works:

# Check DNS propagation
dig api.yourdomain.com

# Test the endpoint
curl -i https://api.yourdomain.com/

# Verify SSL certificate
openssl s_client -connect api.yourdomain.com:443 -servername api.yourdomain.com | grep subject

Expected Results:

• DNS query returns Lambda Function URL hostname as CNAME target
• HTTP request succeeds with same response as Lambda URL
• SSL certificate shows AWS-managed certificate (not your custom domain)

We ran a series of experiments to explore how far Generative AI can currently be pushed toward autonomously developing high-quality, up-to-date software without human intervention. As a test case, we created an agentic workflow to build a simple Spring Boot application end to end. We found that the workflow could ultimately generate these simple applications, but still observed significant issues in the results—especially as we increased the complexity. The model would generate features we hadn't asked for, make shifting assumptions around gaps in the requirements, and declare success even when tests were failing. We concluded that while many of our strategies — such as reusable prompts or a reference application — are valuable for enhancing AI-assisted workflows, a human in the loop to supervise generation remains essential.

Announcing the Official PHP SDK for MCP

The PHP Foundation, Anthropic’s MCP team, and Symfony are collaborating on the official PHP SDK for the Model Context Protocol (MCP). Our goal is a framework-agnostic, production-ready reference implementation the PHP ecosystem can rely on.

Covariance and Contravariance in PHP

Before we dive into the details and code examples, let me quickly define covariance and contravariance:

Covariance: Making something more specific
Contravariance: Making something less specific

Now let's dive in and see how these concepts apply to PHP.

Break Stuff on Purpose

Strengthen your system’s ability to recover by intentionally causing and resolving failures

Nothing Beats Kindness

The whole purpose of refactoring is to make us program faster, producing more value with less effort.

and

But I think the most dangerous way that people get trapped is when they try to justify refactoring in terms of "clean code", "good engineering practice", or similar moral reasons. The point of refactoring isn't to show how sparkly a code base is -- it is purely economic. We refactor because it makes us faster -- fastor add features, faster to fix bugs.

-- From Refactoring: Improving the Design of Existing Code (Martin Fowler and Kent Beck), page 56