AppSync & GraphQL on AWS

The plain-language idea

This track assumes the GraphQL fundamentals already covered elsewhere — the query language itself, over/under-fetching, the N+1 problem. AppSync is AWS's managed GraphQL service: instead of standing up, hosting, and scaling your own GraphQL server, you give AppSync a schema, and it runs the endpoint, wiring each field to a resolver connected directly to a backend data source — DynamoDB, Lambda, another HTTP API, or other AWS services — without you building the query execution engine a self-hosted server would need.

Beyond "hosted GraphQL," AppSync's managed features cover ground a self-hosted server usually has to build by hand:

• Direct data-source resolvers — a query or mutation can map straight to a DynamoDB operation through a resolver template, with no Lambda function running at all for straightforward reads and writes.
• Real-time subscriptions — a Subscription type in the schema that pushes updates to connected clients over a managed WebSocket connection whenever a matching mutation happens, without hand-building connection management.
• Offline sync with conflict resolution — client SDKs let an app write data while offline and reconcile it against the server once connectivity returns, using a conflict-resolution strategy (like optimistic concurrency via a version field, or a custom Lambda resolver) you choose.

See it in a real thing: a mutation that triggers a live subscription

type Mutation {
  createOrder(input: OrderInput!): Order
}

type Subscription {
  onCreateOrder: Order
    @aws_subscribe(mutations: ["createOrder"])
}

A client calls createOrder — AppSync's resolver writes directly to DynamoDB, no Lambda involved. Every client subscribed to onCreateOrder receives the new order over its already-open WebSocket connection, in real time, without polling. Building this by hand outside AppSync means standing up a WebSocket API, wiring a pub/sub layer (commonly SNS or SQS underneath), and managing connection state yourself.

What people usually miss

Watch out

• A subscription is a specialized query delivered over a persistent connection, not a general pub/sub system. It fires specifically when a matching mutation runs through AppSync — it isn't a generic message bus you can publish arbitrary events to from anywhere.
• Offline conflict resolution is a toolkit, not a solved problem. AppSync gives client SDKs and server-side hooks for handling conflicting writes, but the actual strategy (last-writer-wins, version-based optimistic concurrency, custom merge logic) is still a decision the team makes, not a default AppSync picks for you.
• A direct-to-DynamoDB resolver skipping Lambda is a real, common pattern — not a workaround. Assuming every GraphQL operation needs a function behind it misses one of AppSync's actual selling points: simple CRUD can go straight from schema to database.
• AppSync's field-level authorization layers on top of Cognito/IAM, the same identity story as the rest of this track — it isn't a separate, standalone auth system; it applies the same identities and rules this track already covers, just enforced per-field instead of per-endpoint.

Why this matters in interviews

"How would you build a real-time notifications feature on AWS?" tests whether a candidate can name AppSync's subscriptions as the managed answer, and reason about when hand-building a WebSocket API plus SNS/SQS would actually be the better call instead (fine-grained protocol control, extreme scale, or infrastructure the team already runs) — rather than defaulting to either option without naming the tradeoff.