Skip to content
academia.sh
tr
Log in

Course Intermediate

Serverless and Edge Computing

Published Updated

By the end of this course

Start course

01

Function-Based Compute

Handing off capacity management: the latency and retry difference across synchronous, asynchronous, and stream-based invocation models, where cold start comes from and what mitigating it costs, the design constraint of memory, duration, and concurrency thresholds, gradual release through versioning and aliases, package size management with shared layers, and why serverless does not fit long-running, state-heavy jobs.

  1. 01 The Serverless Concept The same day's workload is run in two arrangements: the always-on instance and the function invoked on demand; idle capacity, requests served at peak, and the hour the night job finishes are counted side by side, the base load is scanned from zero to sixty-five thousand to work out the break-even load level, and the ten handed-off decisions with the eight numbered constraints that come back in return are gathered into a single ledger.
  2. 02 Function Invocation Models The same validation job is run through three invocation models and four things are counted separately: the latency the caller sees, who sees the error, who owns the retry, and the rate of repeated processing; batch read size is then scanned from one to two thousand five hundred in the stream-based model to work out call count, extra processing, the healthy records dragged into the dead letter queue, and the batch that no longer fits the duration limit.
  3. 03 Cold Start A warm pool model is run to count whether a request finds an instance: in three fictional traffic profiles, the cold call rate, the duration added to latency, and the requests that land in the queue are measured; pool lifetime is scanned from zero to eighteen hundred seconds to work out the threshold where the cold rate drops and the idle instance-seconds that come back in return, and three mitigation paths are priced separately.
  4. 04 Resource and Duration Limits Three thresholds — memory, duration, and concurrency — are applied to a set of twelve jobs, and how many jobs do not fit is counted; scanning memory tiers shows duration dropping while unit cost draws a valley, with the cheapest point landing in the middle; when the concurrency limit is shared at the account level, one function starving another is measured with the throttle rate and the lost requests.
  5. 05 Versioning and Aliases Weight shifting through the alias is measured: the version stays unchanged, the alias moves. At every step, the affected requests and the round where the difference disappears are counted; cold start's interference with the canary measurement and rollback being a single key turn are worked out separately.
  6. 06 Shared Layers and Dependencies The relationship between package size and cold start is scanned: when dependencies move to a shared layer, the package shrinks but the bytes pulled do not change. Version pinning's storage cost, a layer update's radius, and an unused dependency's cost in bytes moved are counted.
  7. 07 Cases Where Serverless Is Not Suitable Five job types are compared on the axes of duration, state, and cost: for each type the item that exceeds the threshold is written by name, and the cost of splitting an unfit job to make it fit is counted as steps, interim state, and failure points. The topic closes with a table showing which job fits serverless, which does not, and why.

02

Event-Driven Services

The layer that connects functions to each other: the event bus's routing and filtering rules, the delivery-guarantee difference between queue and topic services, workflow orchestration with step-based state machines, the missed-run and overlapping-run behavior of scheduled triggering, the API gateway service that handles endpoint management and authorization, and the notification services that manage sending reputation.

  1. 01 Event Bus Handing the routing decision to the event bus: scanning, as the rule set widens over the same 2,000-event stream, the number of events that match no rule and the number that go to multiple targets; the effect on the number of events carried of whether the filter sits in the rule or in the target; and measuring how a new rule can pick up traffic without disturbing any existing number.
  2. 02 Queue and Topic Services The constraints that come from taking the queue as a service: counting the five remaining configuration items, scanning visibility timeout across six values to measure the double processing a short duration produces against the recovery delay a long one produces, the dead-letter drop time turning out to be a derived number, and comparing the fan-out difference between queue and topic services in terms of delivery and configuration items.
  3. 03 Workflow Orchestration Running a five-step invoicing flow as a state machine: measuring retries and compensation steps per step, the constraints that come from moving a flow's state into the orchestrator, and counting the difference between building the same flow inside a function versus handing it to an orchestrator in terms of cost and locked concurrency.
  4. 04 Scheduled Triggering The kind of guarantee that comes from handing the clock to a service: measuring, across a thirty-night batch-invoicing run, the number of duplicate invoices two triggers arriving in the same minute produce; the idempotency key closing that gap while leaving a missed run uncompensated; and counting, under clock drift, the difference between deriving the work window from trigger time versus from the data.
  5. 05 API Gateway Service The numbers behind taking the gateway as a service: the configuration item count of a twelve-endpoint surface, the effect of doing authorization at the gateway on function call count and the break-even cache hit rate, showing by scanning the timeout threshold that the gateway does not hide cold start, and that a timed-out request keeps completing in the function.
  6. 06 Notification and Email Services The constraint that comes from handing sending to a service: bounced messages and complaints coming back as events, scanning this feedback stream's processing rate to measure the reputation score at day thirty, the number of throttled days, and the number of messages delivered, and comparing the cost of processing feedback against the delivery cost of not processing it.

03

Edge Computing

Moving computation to the user: the edge runtime model with isolates, request processing and routing at the edge, edge storage with key-value and object store connections, durable objects that hold coordinated state at the edge, moving asynchronous work to the edge and its duration limit, and how duration, memory, and compatibility constraints shape design.

  1. 01 Edge Runtime Model The isolate is compared to the container and the virtual machine on the same metrics: startup latency and memory baseline by order of magnitude, the offered interface surface item by item. Cold start's disappearance is counted, along with the seven missing items it comes with and the cost of working around them.
  2. 02 Request Processing and Routing The same request set is processed at three places — the edge, the region, and the origin — and how many network round trips and milliseconds each placement adds is counted. For the four job types that can run at the edge, the share of requests that never reaches the origin is worked out, and the work that cannot be done at the edge is named.
  3. 03 Edge Storage The edge key-value store is fast for reads, slow for writes, and its consistency is delayed. The propagation window is scanned and stale reads are counted for each value; the round-trip count and egress cost of reaching the object store are compared in a fictional unit, and the store's size limit is worked out as a constraint.
  4. 04 Durable State Objects A single-writer object model is run for the same key: lost updates drop to zero under concurrent requests. Two constraints that come back in exchange are counted — the single instance queuing per request and the object's geographic pinning — and which of a counter, a room, and a lock scenario fits is written down.
  5. 05 Edge Queues and Scheduled Jobs The same job set is processed in the center queue and the edge queue; the queue-entry trip, where the job runs, and the result's return path are counted separately. The edge queue's four constraints and the region a scheduled job fires in are measured.
  6. 06 Bindings and Service Connections The same resource is reached by building a client at runtime and by a declarative binding; lines of code, startup work, where the credential sits, and the moment an error is seen are counted. The binding's scope and portability constraints are also measured.
  7. 07 Edge Limits The edge's three thresholds are applied to a set of twelve jobs; the cost of splitting is worked out in extra trips and failure points, and the three cases where the edge does not pay off are counted. The course wrap-up sums the delegated decision and the constraint of twenty lessons.

Final exam

Serverless and Edge Computing — Final Exam

In preparation

This course's question bank is not complete yet. The exam opens here automatically once enough questions are added.

Start typing to search.

↑↓ ↵ Esc navigate · open · close