DEV Community: Shantanu Gonade

The EventBridge Myth That Hid a Double-Registration Bug and a Race Condition in My Serverless App

Shantanu Gonade — Wed, 17 Jun 2026 08:03:46 +0000

How a routine architecture review turned up a team myth about EventBridge and a double-booking bug hiding in plain sight — and why the two were the same problem wearing different hats.

Three weeks ago, I closed out a 14-week build of TEMS (Terrapin Events Management System) — a serverless event management platform for the University of Maryland. Students browse and register for campus events, organizers manage capacity and waitlists, admins approve events and watch a metrics dashboard. Under the hood: a single-table DynamoDB design, an AppSync GraphQL API, Cognito auth, EventBridge wiring eight backend services together, 54 Lambda functions, the works.

TEMS high-level architecture: AppSync → Lambda → DynamoDB, with EventBridge wiring eight backend services and Cognito handling auth. 54 functions, one custom bus, one table.

The completion report I wrote for myself said what every completion report says:

- 100% of planned features implemented

- AWS Well-Architected Framework compliance

- Production-grade security and scalability

Project Status: COMPLETE AND PRODUCTION-READY

I believed it. I’d written tests. I’d followed the patterns from the AWS docs I’d read. I’d even left myself meeting notes during the build with little architecture decisions and “why we did it this way” rationales — including one note that EventBridge would “automatically deduplicate events within 24 hours,” so a few rough edges in the registration flow weren’t a big deal.

Then, mostly out of curiosity, I pointed an AI architecture audit at the codebase and asked it to compare three things against each other: what the docs claimed, what the code actually did, and what AWS’s current (2026) guidance recommends for each pattern.

It came back with a numbered list of findings. Two of them stopped me cold — not because they were exotic, but because they were the kind of thing a senior reviewer catches in five minutes and a solo developer (me, several months deep in feature work) walks past a hundred times without seeing.

This is the story of those two findings, and why they turned out to be the same bug.

The setup: as-described vs. as-built vs. best-practice

Before the findings, a quick word on the audit itself, because the shape of it is as useful as the content.

I didn’t ask for a generic “review my AWS architecture” pass — that tends to produce a list of platitudes (“consider adding monitoring,” “review your IAM policies”) that are true of literally every AWS account on Earth. Instead, I gave it three things to triangulate:

What the project documentation claims — architecture docs, meeting notes, the completion report.
What the code actually does — every serverless.yml, every handler, the GraphQL schema, the DynamoDB table definition.
What AWS currently recommends — for each pattern in use (EventBridge, DynamoDB single-table design, idempotency, CQRS-style read models).

Then I asked it to flag every place those three things disagreed, with file and line citations for every claim.

That last part matters. An AI that says “your event-driven architecture could be more robust” is not useful. An AI that says “register.ts:161-199 writes two PutCommands keyed on a freshly generated registrationId, with no ConditionExpression enforcing uniqueness on (eventId, userId) — here's the AWS doc on conditional writes that addresses this" is useful, because you can go open that file and check it yourself in thirty seconds. Good audits — human or AI — are falsifiable. If you can't verify a finding against the actual repo, throw it out.

With that framing, here’s what came back.

Finding 1: “EventBridge automatically deduplicates events”

Buried in my own meeting notes from the week I wired up the registration flow was this line, paraphrased: EventBridge automatically deduplicates events, so duplicate RegistrationCreated events within a 24-hour window won't cause problems downstream.

I have no idea anymore where I picked that up. Maybe I was thinking of SQS FIFO queues and their 5-minute deduplication window. Maybe I half-remembered something about EventBridge Pipes. Either way, it had the structure of a fact: specific (24 hours), plausible (AWS services do dedupe things sometimes), and — crucially — comforting. If it’s true, a bunch of edge cases I hadn’t fully thought through just… go away.

The audit’s response was blunt: Amazon EventBridge provides at-least-once delivery and has no native event-level deduplication. None. Not in 24 hours, not ever. If a producer calls PutEvents twice with logically identical payloads, EventBridge will happily deliver both, to every matching rule, as two separate events. (There's PutEvents request-level retry behavior if the API call itself fails and you retry it, but that's a different thing from "the same business event was generated twice by my own application code," which is the case that actually matters here.)

For TEMS specifically, that means every consumer of RegistrationCreated, WaitlistAdded, WaitlistPromoted, and friends — published from register.ts:224-242 and waitlist-manager.ts onto our custom bus (TemsEventBus, with a 30-day replay archive and a DLQ behind it) — has to assume it might receive the same logical event twice and either be naturally idempotent (a second "send confirmation email" is harmless-ish, if annoying) or actively de-duplicate (a second "decrement available capacity" is not harmless at all).

On its own, this is a “fix the docs, add a code comment” finding. Mildly embarrassing, low stakes. I’d have fixed the meeting note, added a // NOTE: EventBridge does NOT dedupe — see comment near the PutEventsCommand calls, and moved on.

Except the audit’s very next finding was about the registration handler. And once I read it, the meeting-note myth stopped being mildly embarrassing and started looking like the reason the second bug had survived this long.

Finding 2: the double-registration bug

Here’s a simplified version of what register.ts does when a student registers for an event (real file: backend/services/registrations/handlers/register.ts):

Read in isolation, every individual piece looks reasonable. There’s an idempotency check! There’s a “already registered” check! There’s an atomic counter increment using DynamoDB’s ADD update expression, which really is atomic! It reads like code written by someone who knew about these problems and was actively guarding against them. (It was. That someone was me, four months ago, clearly aware idempotency was a thing — just not finishing the thought.)

But walk through what actually happens when a student double-clicks “Register” — or, more realistically, taps it once on flaky dorm wifi, the request hangs, they tap again:

Request A arrives. No idempotencyKey (the frontend doesn't currently send one — it's optional, remember). isUserRegistered runs its Query, finds nothing, returns false. Capacity check passes. A is now mid-flight, about to write.
Request B arrives a few hundred milliseconds later, before A’s PutCommands have landed. isUserRegistered runs again — and because A hasn't written yet, B also gets false. Capacity check passes again.
Both requests generate their own fresh registrationId via nanoid(16). Both write two PutCommands each — USER#{userId}/REGISTRATION#{id} and EVENT#{eventId}/REGISTRATION#{id} — with completely different sort keys, because the IDs are different random strings. Nothing in DynamoDB rejects this. There's no ConditionExpression. There's no uniqueness constraint anywhere that says "a given (eventId, userId) pair may only have one active registration row."
Both requests call atomicIncrementRegistered(eventId, 1). This part is atomic — it's a DynamoDB UpdateItem with ADD registeredCount :inc — so the counter correctly goes up by 2. Correctly, for the wrong reason: it's accurately counting two registrations that should never have both existed.
Both requests publish a RegistrationCreated event to EventBridge.

End state: one team, two registration records, two QR codes, two confirmation emails, and an event capacity counter that’s now off by one in the direction of “oversold.” Do this across a popular event during a registration rush — say, the first ten minutes after a big lecture’s extra-credit event opens up — and you get a slow leak of phantom registrations that nobody notices until check-in day, when the room is fuller than the headcount predicted and a few students’ QR codes scan into a now-”full” event that capacity-checks are blocking new registrants from.

The race window is small — milliseconds — but it doesn’t need to be wide. It needs to be non-zero, and it needs traffic. A campus event platform at registration-rush time has both.

Where the two findings meet

Here’s the part that actually changed how I think about this codebase.

The “fix” for the double-registration bug is, fundamentally, idempotency at the write layer: make it so that no matter how many times “register user X for event Y” is requested, at most one registration record can ever exist for that pair. That’s a DynamoDB-side guarantee — a conditional write or a transaction — and it’s completely independent of anything downstream.

The myth said: “don’t worry about duplicate events, EventBridge will collapse them within 24 hours.” If I’d genuinely believed that and stopped there, I’d have been solving the wrong layer entirely — even in a world where EventBridge did dedupe events, that would do nothing to stop the DynamoDB writes in steps 3 and 4 above from happening twice. The duplication isn’t an EventBridge problem. It’s not even really a “two Lambda invocations” problem. It’s that the database has no opinion about whether a given (eventId, userId) pair is allowed to appear more than once, and nothing upstream of the database closes that gap.

The myth didn’t cause the bug. The bug would exist with or without it. But I think the myth is a big part of why the bug survived a full build cycle, a test suite with >80% coverage, and a “production-ready” sign-off — because every time some part of my brain noticed “hm, this registration flow doesn’t have a hard uniqueness guarantee,” another part of my brain had a half-remembered, comforting, wrong answer ready: that’s fine, it gets cleaned up downstream. Nothing gets cleaned up downstream. There is no downstream cleanup. There never was.

That’s the actual lesson, more than either finding individually: a wrong belief about how your infrastructure behaves doesn’t just cost you when you act on it directly — it costs you every time it talks you out of fixing something else.

The fix (briefly — full tutorial is next)

The shape of the fix is: give every (eventId, userId) pair a single, deterministic "claim" item —

{
  PK: `EVENT#${eventId}`,
  SK: `REGCLAIM#${userId}`,
  // ...
}

— and write it with ConditionExpression: 'attribute_not_exists(PK)', ideally inside the same TransactWriteItems call that creates the two registration records and the idempotency record. The second concurrent request's conditional write fails with a ConditionalCheckFailedException, the handler catches that and returns the existing registration instead of creating a new one, and the race window closes — not because it got narrower, but because DynamoDB itself now rejects the collision regardless of timing.

There’s also a more turnkey option: AWS Lambda Powertools’ Idempotency utility, which wraps a handler with makeIdempotent() and a DynamoDB-backed persistence layer, handling the claim-record lifecycle, TTLs, and in-flight request coalescing for you. Making idempotencyKey a required argument (instead of optional, as it is today at register.ts:31 and in the GraphQL schema's registerForEvent(eventId: ID!, idempotencyKey: String)) is part of this too — an idempotency mechanism that callers can opt out of by simply not passing a key isn't really a guarantee, it's a suggestion.

I’m walking through both approaches — deterministic conditional writes and the Powertools utility, with before/after code and a way to actually test for the race condition — in the companion piece: Stop Relying on EventBridge to Dedupe Your Events: A Practical Guide to Idempotent DynamoDB Writes ** soon **.

What I’d tell you if you’re about to run this audit on your own project

A few things I’d do differently next time, and would suggest if you try this on your own codebase:

Ask for citations, not opinions. “Is this secure?” gets you a essay. “Show me every IAM policy with a Resource: '*' and the line number" gets you a punch list. The second one is useful at 11pm before a launch.
Separate “as described” from “as built” from “current best practice,” explicitly. A surprising amount of value in this audit came from the gap between my docs and my code — not from either one alone. My own completion report claimed 5 backend services; the code has 8. That’s not a security issue, but it’s a signal that the docs were written from memory, not from the repo — which made me trust the other claims in those docs less, including the EventBridge note.
Verify anything time-sensitive against current docs, especially for fast-moving services. AWS behavior and tooling changes. The Lambda Powertools Idempotency utility I’m using in the next article didn’t always look like it does now. An audit’s value decays; treat findings as a snapshot, not gospel, and re-check the load-bearing ones.
The boring findings are often connected to the interesting ones. I almost filed the EventBridge note under “fix the comment, move on.” It turned out to be load-bearing for a much bigger miss. If an audit turns up something that smells like “minor docs inaccuracy,” ask what decisions were made on the assumption that the inaccurate thing was true.

TEMS is still “production-ready” in the sense that matters most: it’s a real system, serving a real use case, and I know exactly what’s wrong with it and how to fix it — which is a state most production systems never quite reach. The completion report needed an asterisk, not a rewrite. But I’m glad I asked the question before someone’s registration silently doubled during finals week.

TEMS is a serverless event management platform built on AWS Lambda, AppSync, DynamoDB, EventBridge, and Cognito. This is the first in a short series on what a structured AI architecture audit found in a “finished” project — next up, the idempotency fix in detail, and a look at how the same FIFO waitlist that handles oversold events is built entirely on DynamoDB.

A Note of Appreciation

This project, and this write-up, wouldn’t exist without the people who supported it along the way.

To Dr. Tony D. B. — thank you for your guidance, your patience, and for holding the work to a standard that made it worth doing properly. Your feedback shaped not just the system, but how I think about building one.

To Rohin Vaidya, Sanskar Vidyarthi, Syed Muhammad Affan and Vishal Patil — thank you for your contributions, your collaboration, and for showing up consistently through every phase of this build. The best parts of TEMS reflect what we figured out together.

I’m grateful to all of you for the time, thoughtfulness, and care you brought to this. It meant more than I can neatly put into a completion report.

Git Repo: https://github.com/shantanu-gonade/terrapin-events

I’m an Android Engineer. I got an AWS Solutions Architect Cert. Here’s why?

Shantanu Gonade — Tue, 16 Jun 2026 17:08:23 +0000

The Bridge: mapping Android architecture to AWS cloud architecture, side by side

For about a year, the same question kept coming back, usually with a slightly puzzled tilt to it: why is an Android engineer studying AWS? I was 3.7 years into writing Kotlin at Samsung — OEM-level Android, Compose, MVVM, coroutines, the works — and here I was, drawing VPC diagrams and memorizing DynamoDB capacity modes for the Solutions Architect — Associate exam. From the outside it looked like a detour. “Go deeper on Android,” people said. “That’s your lane.”

I want to tell you about the realization that made me ignore that advice, because it turned out to be the opposite of a detour. Studying cloud architecture made me a measurably better Android engineer — and the reason is something I now believe most people on both sides of the mobile/backend line miss.

The moment it clicked

The honest origin story isn’t glamorous. It started with a retry.

I was debugging a sync bug in a feature that talked to a backend I hadn’t built. The client would fire a write, the write would occasionally fail, and my retry logic would dutifully fire it again — and sometimes the user would end up with the operation applied twice. I’d written the client the way a mobile engineer writes a client: assume the request either succeeds or fails, and if it fails, try again. Clean. Reasonable. Wrong.

A mobile retry bug caused by missing idempotency — why a successful server write got duplicated by a client retry.

Because the thing I hadn’t internalized was what happened on the other side of the wire. The request had succeeded — the server had committed it — and only the response had been lost on a flaky connection. My retry wasn’t recovering from a failure; it was duplicating a success. The fix wasn’t in my Kotlin. It was in understanding that the backend needed to be idempotent, and that my client needed to send a key the server could use to recognize “I’ve already seen this one.” That’s a distributed-systems concept, and I was treating it as a networking annoyance.

That bug embarrassed me a little, and embarrassment is a good teacher. I realized I’d been doing something subtly limiting for years: I treated the backend as a vending machine. I put a request in, I got a response out, and the inside of the machine was somebody else’s problem. But my app’s behavior — how it retried, how it paginated, how it cached, how it degraded offline — was entirely shaped by a system I refused to reason about. Mobile is increasingly full-stack. Mobile DevOps — the CI/CD, the release infrastructure, the build pipelines I work in every day — lives in the cloud. I kept bumping into the backend and choosing to look away. The cert was me deciding to look.

The realization underneath the realization

Here’s the part I didn’t see coming. I expected studying AWS to teach me about the backend. It did. What I didn’t expect was that it would re-explain my own job to me — because senior Android architecture and cloud architecture are, structurally, the same mental model wearing different clothes.

Animated map of all 7 Android-to-AWS architecture parallels, from ViewModel/Lambda to Hilt/Infrastructure-as-Code

The skill underneath both isn’t “Android” and it isn’t “AWS.” It’s drawing boundaries: between state and effects, between producers and consumers, between the read path and the write path, between what you declare and what the framework assembles. Once I saw that, the AWS material stopped feeling foreign and started feeling like my own architecture diagrams with the labels swapped. Let me walk the parallels, because this is the actual payload of the post.

Parallel 1 — the stateless state holder

Parallel 1: Android ViewModel vs. AWS Lambda — both stateless handlers that turn input into output

In modern Android, a ViewModel exposes an immutable UiState and holds no long-lived mutable state of its own. The UI sends events up; the ViewModel reduces them into a new state and emits it down. It’s a function from input to output with a thin lifecycle wrapper. That’s why it’s the easy part of the app to unit-test — you hand it an input, you assert on the output, no environment to stand up.

A Lambda handler is the same shape. It holds no durable state between invocations; it takes an event in, derives a response, and returns. Anything it needs to persist goes out to a store. It’s testable for exactly the same reason a ViewModel is: input in, output out.

// Android — ViewModel as a stateless-ish state holder
class CartViewModel(private val repo: CartRepository) : ViewModel() {
    private val _uiState = MutableStateFlow(CartUiState())
    val uiState: StateFlow<CartUiState> = _uiState.asStateFlow()

    fun onAction(action: CartAction) {
        when (action) {
            is CartAction.AddItem -> _uiState.update { it.copy(items = it.items + action.item) }
            // events in → new immutable state out. No hidden mutable state.
        }
    }
}tyt

// AWS - Lambda handler: same shape, different runtime
export const handler = async (event: AddItemEvent): Promise<CartResponse> => {
  // event in → response out. No durable state held between invocations.
  const updated = applyAddItem(event.cart, event.item);
  await ddb.put({ TableName: TABLE, Item: updated }); // persistence goes OUT
  return { cart: updated };
};

Look at the two and the resemblance is almost rude. Both refuse to hold long-lived mutable state. Both push persistence to the edge. Both are pure-ish cores wrapped in a platform-managed lifecycle. The day I saw the Lambda and the ViewModel as the same object, AWS stopped being a new subject.

Parallel 2 — model data for the queries you actually make

Parallel 2: Room offline-first database vs. DynamoDB single-table design — model your schema for the queries you run

Offline-first Android puts a local Room database as the source of truth: the UI reads from Room, a sync layer reconciles Room with the remote, and the app stays usable on a subway with no signal. The non-negotiable rule of doing this well is that you model your tables for the queries the screens actually run — not for some clean normalized picture of the domain. If a screen needs “the last message per conversation, sorted by time,” you shape the data so that’s one cheap query, not a join you reassemble in Kotlin.

DynamoDB single-table design is that rule with the volume turned up. There are no joins; you list every access pattern up front and design partition/sort keys so each one is a single, cheap query, then add a read-model cache for the hottest paths. Same discipline, same trap: people who model DynamoDB like a relational schema hate it, exactly like people who model Room around entities instead of screens end up with sluggish lists and N+1 reads.

Both are the same instruction: the questions you’ll ask of the data are the design input. The schema falls out of the questions, not the other way around. I’d been doing this on the client for years without naming it. AWS gave me the name and showed me it scales all the way up.

Parallel 3 — decouple the producer from the consumer

Parallel 3: Kotlin Flow vs. AWS EventBridge/SQS — decoupling producers from consumers with backpressure and queue-based load leveling

Compose architecture runs on unidirectional data flow: events down, state up, with Kotlin Flow as the reactive spine. A producer emits; collectors react; and crucially, Flow gives you backpressure — a slow collector doesn’t force the producer to block or drop on the floor, it buffers or conflates on defined terms.

The backend twin is event-driven architecture. A service does its work and emits a domain event onto EventBridge (or drops a message on SQS); other services subscribe and react on their own time. The producer doesn’t call the consumer and doesn’t wait on it. And the queue does the same job Flow’s backpressure does on the client: SQS queue-based load leveling absorbs a burst so a spike in producers doesn’t knock over the consumers — you bound concurrency instead of overwhelming the downstream.

There’s a deeper structural-concurrency rhyme here too. Coroutines’ structured concurrency bounds and scopes the work a screen is allowed to spawn — when the scope dies, the children die, no leaks. Queue-based leveling bounds and scopes the work the backend is allowed to run at once. Both are answers to the same question: how do I absorb bursts without unbounded concurrency taking the system down? I started writing better Flow code — conflating where I should, choosing the right buffer strategy — because SQS made me think explicitly about what a consumer does when the producer outruns it.

Parallel 4 — declare your dependencies, let the framework assemble them

Parallel 4: Hilt dependency injection vs. AWS Infrastructure-as-Code — declare what you need, let the framework wire it

This is the parallel that surprised me most, because the two technologies look nothing alike on the surface.

Hilt (Dagger) is a dependency-injection graph. You don’t construct your Repository and hand-thread its ApiService and Database through five constructors; you declare how each thing is provided, and the framework assembles the graph and injects what each consumer asked for.

// Android — Hilt: declare the dependency, the framework wires the graph
@Module
@InstallIn(SingletonComponent::class)
object DataModule {
    @Provides @Singleton
    fun provideCartRepo(api: CartApi, db: AppDatabase): CartRepository =
        CartRepositoryImpl(api, db) // you declare; Hilt assembles & injects
}

Infrastructure-as-Code is the same idea pointed at cloud resources. You don’t click through a console wiring a Lambda to a DynamoDB table to an IAM role by hand; you declare the resources and their relationships, and the framework (CloudFormation / the Serverless Framework / Terraform) assembles the graph and provisions what each piece needs.

# AWS — IaC: declare the resource, the framework provisions & wires it
functions:
  addItem:
    handler: cart.handler
    events: [{ http: { path: /cart, method: post } }]
    # declare what it needs; the framework grants the table dependency below
    iamRoleStatements:
      - { Effect: Allow, Action: [dynamodb:PutItem], Resource: !GetAtt CartTable.Arn }

Both are the same move: stop assembling dependencies by hand; declare them and let a framework build the graph. Hilt’s @Provides and an IaC resource block are the same sentence in two languages. After IaC, I stopped resenting Hilt’s boilerplate and started seeing it as the client-side instance of a pattern I now trusted at scale.

The fifth one — boundaries that scale a team

I’ll name a fifth quickly because it’s the one senior engineers feel most. Gradle multi-module boundaries — :feature:cart, :core:network, an api module a :feature depends on versus the impl it doesn’t see — exist to enforce boundaries so a codebase and a team can scale without everything depending on everything. Microservice and service boundaries on the backend are the identical concern: you split so teams can ship independently and a change’s blast radius is bounded. The repository pattern abstracting your data sources is, on the backend, an API gateway or service layer abstracting the systems behind it. Same instinct, same payoff, same failure mode when you draw the lines wrong.

Where the analogy breaks — and why that’s the most valuable part

Where the Android-AWS analogy breaks: cold starts, distributed failure, and eventual consistency

If I stopped here, this would be a tidy little “everything is the same” essay, and that would be dishonest. The analogy is powerful precisely up to the point where it shatters, and the shattering is where the cert earned its keep.

Cold starts don’t exist on a device. Your ViewModel is already in memory; your code is warm. A Lambda can be cold — a fresh container, an init penalty, a p99 that’s nothing like your p50. On a device you optimize for jank and battery; in the cloud you optimize for an entirely different latency distribution, one with a long tail your client will feel. Understanding that tail changed how I design clients: I now expect the occasional slow first response and build the UI to stay responsive through it, instead of assuming the backend is as warm as my ViewModel.

Partial and distributed failure barely exist on a device. On the client, an operation mostly succeeds or fails as a unit, locally, observably. In a distributed system, a request can succeed on the server and fail to reach the client (my original retry bug), or half a fan-out can complete while the other half is still in flight. There’s no single “did it work?” you can read. This is why idempotency and explicit retry semantics aren’t backend trivia — they’re contracts my mobile client has to participate in. I write retries differently now: with idempotency keys, with the assumption that “no response” does not mean “no effect.”

Eventual consistency isn’t a thing your screen normally has to model. A device reads its own writes from local storage instantly. A distributed read replica might not have caught up yet. Designing for that — knowing that “I just wrote it but the read came back stale” is correct behavior, not a bug — has no real equivalent in single-device Android. But the moment your app reads from a system that’s eventually consistent, your UI has to account for it: optimistic updates, reconciliation, “pending” states. The cert is what let me see that coming instead of filing a phantom bug.

These three — cold starts, distributed failure, eventual consistency — are the load-bearing differences. And here’s the thing: learning where the parallel ends is exactly what made me a better mobile engineer. Not the similarities — the similarities just made the material learnable fast. The differences are what let me design clients that cooperate with the system they live inside: offline-first sync that tolerates eventual consistency, retries that assume idempotency, pagination and caching tuned to a real latency tail rather than an imagined instant backend.

Why this makes me stronger on both sides

Full-stack architecture diagram: Android client (Kotlin, Compose, Hilt) connected to a serverless AWS backend (Lambda, DynamoDB, EventBridge)

I came out of the Solutions Architect cert a better Android engineer, and it’s not the line on the résumé — it’s the second pair of eyes. When I design a screen now, I’m also thinking about the shape of the system feeding it: what its consistency guarantees are, where it can be slow, how it fails, what it costs to scale. When I reason about a backend, I bring the client’s reality — that latency and failure aren’t abstractions, they’re something a human is staring at on a phone, waiting.

Realization: It’s the same mental map

I’ve now built both directions for real — a fully serverless app on AWS (single-table DynamoDB, 54 Lambdas, EventBridge) and OEM-level Android at Samsung — and the throughline is that the architecture instincts transfer almost completely, except at the three seams above, which are precisely the seams you have to get right. Mobile is going full-stack whether mobile engineers come along or not. The ones who reason about the whole system, instead of treating the backend as a vending machine, are going to build clients that feel inexplicably more solid than everyone else’s. That’s the bet I made. So far it’s paying off in cleaner retries, smarter offline behavior, and a much shorter conversation with backend engineers when something’s on fire.

If you write mobile and the backend still feels like a black box: pick the one cert or the one project that forces you to open it. You won’t come back a backend engineer. You’ll come back a better mobile one.

Recap diagram: all 7 Android-AWS architecture parallels and the 3 places the analogy breaks, in one map

Parallels mapped: ViewModel↔Lambda · Room offline-first↔DynamoDB single-table+cache · UDF/Kotlin Flow↔EventBridge/reactive streams · structured concurrency↔SQS load leveling · Hilt DI↔Infrastructure-as-Code · Gradle module boundaries↔service boundaries · Repository pattern↔API/service layer.

Where it breaks: cold starts · distributed/partial failure · eventual consistency.

I’m Shantanu — Android engineer and AWS Certified Solutions Architect — Associate. I build full-stack — Android clients and the serverless backends behind them. I write about mobile and cloud at shantanu-gonade.com. Open to senior Android and mobile-platform roles — let’s connect.

Android After Google I/O 2026

Shantanu Gonade — Tue, 09 Jun 2026 02:13:49 +0000

Edge-to-edge is mandatory. Predictive back now owns your stack. Compose 1.11 ships Grid and Styles. Navigation 3 is stable. Kotlin 2.4 context parameters are production-ready.

If your app targets Android 16 (API 36), two things will break the moment a user upgrades: your status bar layout and your back button handler. Not "might break." Will break.

Google I/O 2026 has a single through-line: Android is now Compose-first. That phrase showed up in every keynote. It isn't marketing. It means Google is putting all future guidance, new APIs, and tooling investment behind Jetpack Compose. Five years after its launch, Compose has graduated from "recommended" to "the only supported path forward." Every change in this article connects back to that shift.

Let's start with what's on fire.

Two Things That Will Break Your App Right Now

Edge-to-Edge Is No Longer Optional

Left: not edge-to-edge. Right: edge-to-edge — the only mode Android 16 supports.

Starting with Android 16 (API level 36), the system ignores WindowCompat.setDecorFitsSystemWindows(window, false). Apps that used true to opt out of edge-to-edge will now render incorrectly — content bleeds behind the navigation bar and status bar without insets applied.

Edge-to-edge is enforced. There is no opt-out flag, no manifest attribute to escape it. You must handle window insets explicitly.

Here is the correct pattern for a full-screen composable in 2026:

Mandatory Edge-to-Edge Activity initialization for apps targeting Android 16 (API 36) using Jetpack Compose.

The enableEdgeToEdge() call replaces the old WindowCompat dance. It sets the correct window appearance flags, handles light/dark status bar icons, and prepares the window for inset consumption.

Inside your screens, use Modifier.consumeWindowInsets and the WindowInsets APIs directly rather than relying on Scaffold to absorb everything silently:

Proper window insets consumption using Scaffold and WindowInsets.safeContent in Jetpack Compose.

The key mistake developers make is passing WindowInsets.Zero to contentWindowInsets to "fix" visual issues, which defeats the purpose of edge-to-edge and creates problems on devices with gesture navigation. Use WindowInsets.safeContent and let the system compose correctly.

Gesture insets: the green zones are controlled by the OS. Never place tappable targets under them.

If you have custom views inside a AndroidView composable, apply insets explicitly:

Applying system bar window insets manually to a legacy Android View inside an AndroidView composable wrapper.

Migration checklist:

Replace all WindowCompat.setDecorFitsSystemWindows(window, true) calls with enableEdgeToEdge()
Replace WindowCompat.setDecorFitsSystemWindows(window, false) calls — they are now no-ops
Audit every Scaffold for missing contentWindowInsets
Test on a device running Android 16 with gesture navigation enabled

Predictive Back: `onBackPressed` Is Dead

Predictive back previews the destination before the gesture commits. On Android 16, your app must support this natively.

On Android 16 (API 36), onBackPressed() is no longer called. KeyEvent.KEYCODE_BACK is not dispatched. If you override onBackPressed in an Activity or Fragment and you have not migrated to the predictive back APIs, your back handling silently does nothing.

This is a hard breaking change, not a deprecation warning.

The correct implementation uses BackHandler in Compose, which wires into the OnBackPressedDispatcher — the only supported path:

Intercepting system back gestures with BackHandler and AnimatedContent in a multi-step Jetpack Compose form wizard.

For the system's predictive back preview animation — the one that shows a shrinking card as you swipe — you get it for free when you use BackHandler. The system intercepts the gesture and shows the preview before your handler fires. You do not write animation code for the default behavior.

Motion spec during a left-edge swipe: the surface scales to 90%, shifts right with an 8dp margin. `PredictiveBackHandler` gives you the progress value to drive this.

For custom back animations (your own content transitioning while the user is mid-swipe), use PredictiveBackHandler:

Driving bespoke screen scale and translation animations using PredictiveBackHandler progress events in Jetpack Compose.

If you still have legacy code that uses onBackPressed, set android:enableOnBackInvokedCallback="false" in your manifest as a temporary escape hatch — but treat it as technical debt with a deadline. It will not be supported forever.

Kotlin 2.4: Context Parameters Are Stable and They'll Change How You Write Compose Code

Kotlin 2.4.0 release notes: context parameters are stable. No compiler flags required.

Kotlin 2.4.0, released in June 2026, promotes context parameters to stable. No compiler flags required. Production-ready today.

Context parameters let a function declare that it needs a value to be "in scope" without the caller explicitly passing it. The compiler injects the dependency from the surrounding scope.

Here is the problem they solve in a Compose codebase. Consider a common pattern — a function that needs both a SnackbarHostState and a CoroutineScope to show snackbar messages:

The old way (lots of plumbing):

Explicitly plumbing SnackbarHostState and CoroutineScope parameters across multiple Compose layout functions (Antipattern).

The new way with context parameters:

Leveraging stable Kotlin 2.4 context parameters to eliminate ambient parameter drilling in Compose UI functions.

The stronger use case: domain-level operations that need infrastructure — logging, analytics, navigation — without threading those concerns through every parameter.

Context parameters work especially well with the NowInAndroid architecture pattern. In a repository that needs both a network client and a local DAO, context parameters let you declare those dependencies at the call site rather than injecting them into the constructor when the caller already has them in scope.

Declaring infrastructure dependencies at the call-site of a Repository using Kotlin 2.4 context parameters.

This is not a replacement for Hilt or dependency injection. Context parameters solve a different problem: eliminating parameter drilling for values that are ambient within a call chain, not values that are injected at construction time.

Compose 1.11: Grid, Styles, and the Testing Overhaul

The Grid API

Compose 1.11 ships a non-scrollable Grid composable for building two-dimensional layouts. This is different from LazyVerticalGrid — Grid is for fixed-size layouts, not infinite lists.

Before Grid, building a dashboard-style layout in Compose required either LazyVerticalGrid (wrong — it's built for infinite content and has overhead for fixed layouts) or nested Row/Column composables (fragile and hard to maintain).

Creating fixed-size dashboard UIs with the Compose 1.11 non-scrollable Grid API and GridItemSpan column spanning.

The GridItemSpan API gives you column-spanning without the SubcomposeLayout gymnastics that were previously required.

The Styles API (Experimental)

The experimental Style {} API separates a component's visual appearance from its structural behavior. Instead of overriding colors, shapes, and textStyle through individual parameters, you declare a style object that carries all visual customization.

Separating layout structure from visual customization using the experimental Compose 1.11 Style component API.

The Styles API is still @ExperimentalFoundationApi in 1.11. Do not ship it in production without understanding that the API surface may change. It is worth understanding now because this is the direction Compose is moving for design system work.

The Testing API Overhaul

Compose 1.11 makes the v2 testing APIs the default. This is a breaking change for test suites that relied on the implicit coroutine execution behavior of v1.

What changed: v1 tests used UnconfinedTestDispatcher, which ran coroutines immediately when launched. v2 uses StandardTestDispatcher, which queues coroutines. They run only when you advance the virtual clock.

Broken asynchronous test pattern under Compose 1.11 due to queued StandardTestDispatcher behavior.

The migration is mechanical: find every runComposeUiTest block that asserts on asynchronous state and add mainClock.advanceUntilIdle() or mainClock.advanceTimeBy(timeMs) after setContent. If you are using waitUntil, review whether it is masking timing assumptions.

The v1 APIs are deprecated but still present in 1.11. They will be removed in a future release.

Navigation 3 Is Stable. Time to Migrate.

Navigation 3's `NavDisplay` handles back-gesture insets automatically. No manual inset wiring required.

Jetpack Navigation 3 reached stable in late 2025 and is now the official navigation library for Compose apps. Navigation 2 (androidx.navigation:navigation-compose) still works, but it will not receive new features.

Navigation 3 does one thing Navigation 2 never could: it gives you full ownership of the back stack as state. The back stack is a List<Any> that you hold in a MutableList — a plain Kotlin value. Navigation observes it; it does not own it.

Migration from Navigation 2 to Navigation 3:

Before:

Application navigation routing structure using explicit NavHost string definitions in Jetpack Navigation 2. After:

Defining type-safe route keys and managing the backstack as observable state using Jetpack Navigation 3.

The back stack is a SnapshotStateList<NavKey>. You can read it, filter it, replace entries, and serialize it for process death restoration — none of which was possible with NavController.

Adaptive layouts with Navigation 3:

Navigation 3's architecture makes two-pane layouts straightforward. The same back stack drives both single-pane (phone) and two-pane (tablet/foldable) layouts:

Adapting a single navigation state backstack natively for single-pane (mobile) and dual-pane (tablet) Android devices.

This pattern — a single back stack that adapts its display — is the official recommended approach for large-screen apps in 2026.

The Platform Goes Compose-First: Widgets, Camera, and Health Connect

Jetpack Glance + RemoteCompose: Widgets Are Finally Good

The same Compose concepts that govern app UI now govern widget UI via Jetpack Glance + RemoteCompose.

Android 17 marks a shift toward a Compose-based development model for all widgets. The vehicle is RemoteCompose, integrated into Jetpack Glance.

RemoteCompose renders full Compose animations on remote surfaces — home screen widgets and car displays. This means your home screen widget can have animated progress indicators, state transitions, and dynamic content without the RemoteViews limitations that made widget development miserable for a decade.

Building home screen widgets featuring live progress animations using Jetpack Glance and RemoteCompose.

This is the first time CircularProgressIndicator in a widget animates properly on the home screen without running a background service to push RemoteViews updates at a fixed interval.

Health Connect: FHIR Medical Records

Health Connect in Android 16 adds write access for medical records in FHIR (Fast Healthcare Interoperability Resources) format. Health Connect is no longer just fitness data.

Saving Fast Healthcare Interoperability Resources (FHIR) medical documentation data inside Android 16 Health Connect.

Apps that read FHIR records must declare READ_MEDICAL_DATA_* permissions (scoped per category). The Health Connect permission dialog now shows users exactly what medical categories an app requests. This is a significant privacy surface — do not request medical permissions unless your app requires them.

CameraX: The Composable Viewfinder

CameraXViewfinder is now a stable @Composable that replaces the old XML-only PreviewView. It handles rotation, surface lifecycle, and camera configuration correctly across all window sizes.

Lifecycle-aware viewfinder rendering using CameraXViewfinder and a continuous capture controller overlay.

The old pattern required wrapping PreviewView in AndroidView, which created lifecycle coordination issues when the composable was paused. CameraXViewfinder handles this correctly.

Your Toolchain Changed Completely: Android Studio, CLI, and the Agentic Era

Android Studio: Narwhal + I/O Edition

The I/O edition of Android Studio ships a LeakCanary profiler task directly in the IDE. You no longer run LeakCanary as a separate tool — memory leak analysis runs as a first-class profiler task in the same panel as CPU and network profilers.

Agent Mode in Gemini (available in Narwhal Feature Drop and later) handles multi-file tasks: generating tests for a feature, refactoring a module to a new architecture pattern, or migrating from Navigation 2 to Navigation 3. The agent formulates a plan, shows it to you, and executes only after you approve each step.

The iOS app porting feature deserves special attention: you point Android Studio at an Xcode project and an AI agent analyzes the Swift/Objective-C code, maps it to equivalent Android patterns, and generates a working Kotlin/Compose app. Migrations that took weeks now take hours. The output is not perfect, but it produces a running app with the correct architecture patterns.

Android CLI: Your App Is Now Scriptable

Android CLI (adb replacement for semantic operations) is stable and exposes your app to AI agents:

# Semantic symbol resolution — ask Android CLI what a class does
android-cli symbols resolve --class="com.example.HomeViewModel"
# Render a Compose preview to file (for visual regression or AI analysis)
android-cli compose preview --composable="HomeScreen" --output=preview.png
# Analyze a file for warnings without opening the IDE
android-cli analyze --file="app/src/main/java/com/example/HomeScreen.kt"
# Run a specific UI test with Gemini-powered natural-language assertions
android-cli test journey --description="Tap the login button, enter test@example.com and password123, verify the home screen shows"

The test journey command is the most significant: natural-language test assertions backed by Gemini's vision model. You describe the user flow in plain English; the CLI converts it into an automated test that runs against your app. This is how Google intends Android to participate in the agentic development toolchain.

Google AI Studio: Build Android Apps From a Prompt

Google AI Studio now builds native Android apps directly. Select "Build an Android app," describe what you want, and the generated project uses Kotlin, Jetpack Compose, Material 3, and the current NowInAndroid architecture patterns. You can connect your Google Play developer account and publish directly to the Internal Test Track without leaving AI Studio.

This matters for prototyping. The generated code is a starting point, not production code — but it generates the right starting point (Hilt, Room, MVVM, Compose Navigation) rather than the dated patterns that earlier code-generation tools produced.

Android 17: What's Coming and the End of Developer Preview

Android 17 is in its first beta as of Google I/O 2026. Two changes worth knowing now:

The Canary channel replaces quarterly developer previews. Android now ships new APIs and features to the Canary release of Android Studio as soon as they pass internal testing. You no longer wait for a scheduled Developer Preview drop. If you want to build against the latest Android platform APIs, stay on the Canary channel of Android Studio. This is the new normal.

Widgets become Compose-native. Android 17 completes the migration of Jetpack Glance to full RemoteCompose. The legacy RemoteViews approach still works, but Google will point all new widget development at Glance + Compose from Android 17 forward. If you have widgets written with RemoteViews, plan their migration.

Pausable composition is now default. Introduced experimentally in Compose 1.10, pausable composition lets the Compose runtime split long composition work across multiple frames — preventing jank on complex screens. It is enabled by default in Android 17's build of Compose. You do not need to change your code, but you should run your UI tests with the Compose 1.11 v2 testing APIs (see Section 3) to ensure they handle the non-immediate execution correctly.

Your Action Items

A correctly handled edge-to-edge bottom bar: scrim for three-button navigation, transparent for gesture navigation. This is what your app should look like on Android 16.

The most urgent changes are in this order:

Ship this week:

Add enableEdgeToEdge() to every Activity and remove all WindowCompat.setDecorFitsSystemWindows calls
Audit every onBackPressed override — migrate to BackHandler or PredictiveBackHandler
Run your Compose tests with Compose 1.11 — any test that fails on StandardTestDispatcher has a hidden timing assumption

Ship this month:

Migrate from Navigation 2 to Navigation 3, Upgrade to Kotlin 2.4 and audit your codebase for context parameter opportunities. Test your app on the Android 16 emulator with gesture navigation enabled.

Plan for next quarter:

Migrate widgets from RemoteViews to Jetpack Glance + RemoteCompose 8. Evaluate CameraX replacement if you use PreviewView in AndroidView Explore Health Connect FHIR if your app touches health data. Enable Android Studio Agent Mode for your most repetitive architectural tasks (generating tests, migrating modules)

What Google I/O 2026 Actually Means

Android in 2026 is not the same platform it was in 2021 when Compose shipped. The ecosystem has converged. Kotlin is the only language. Compose is the only UI toolkit. MVVM with Hilt and Flow is the official architecture. Navigation 3 gives you back-stack as state. The toolchain generates apps that follow these patterns by default.

Five years of investment in Compose is paying off at the platform level: widgets, car displays, Wear OS tiles, and TV all converge on the same Compose model. The XML layout editor, Fragments, ViewPager2 — these are now legacy APIs, maintained but not advanced.

The developers who win in this cycle are the ones who use today's stack to its depth — not the ones who maintain the widest possible backward compatibility. Android 16's mandatory edge-to-edge and killed onBackPressed are not aggressive changes. They are the platform finally enforcing what it recommended for two years.

Your users already expect apps to feel like part of the OS. Now the OS enforces it.

All code in this article targets Android 16 (API 36), Kotlin 2.4, Compose 1.11, Navigation 3, and uses the NowInAndroid architecture patterns with Hilt and StateFlow. The minimum supported SDK in examples is API 24.