- Home
- Skills
- Williamzujkowski
- Cognitive Toolworks
- Cloud Edge Architect
cloud-edge-architect_skill
- Python
5
GitHub Stars
3
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill williamzujkowski/cognitive-toolworks --skill cloud-edge-architect- CHANGELOG.md2.3 KB
- index-entry.json772 B
- SKILL.md15.5 KB
Overview
This skill designs edge computing architectures that combine CDN integration, edge functions, and IoT edge patterns to minimize latency and reduce origin load. It produces platform recommendations, caching hierarchies, state-sync patterns, security controls, and deployment manifests tailored to Cloudflare, AWS, or Azure. Use it to get fast pattern suggestions or a production-ready architecture with monitoring and runbooks.
How this skill works
The skill inspects workload inputs (latency requirements, deployment scope, workload_type, platform_preference, connectivity_model) and runs pre-checks for size limits, runtime constraints, and regional support. It classifies the workload, selects an appropriate platform, generates a layered architecture (CDN PoP → regional edge → origin shield → origin), and outputs caching TTLs, state synchronization strategy, security hardening, monitoring metrics, and platform-specific deployment manifests. It aborts or flags designs that violate constraints (too-low latency, oversized functions, strict ACID needs, regulatory restrictions).
When to use it
- Latency-critical apps targeting <100ms global responses
- Global content distribution with CDN acceleration and edge caching
- IoT deployments needing local processing and intermittent connectivity
- Edge AI inference for privacy or bandwidth savings
- Bandwidth optimization and origin offload to reduce costs
- Geo-distributed workloads needing regional data residency
Best practices
- Validate latency_requirements (10ms–1000ms) and abort if <10ms; use colocation instead
- Prefer JavaScript/WebAssembly for edge functions; keep code under platform size limits
- Cache static assets long (1 day–1 year), dynamic content short (1–60s) with stale-while-revalidate
- Use KV stores or CRDTs for edge state; choose event sourcing for complex sync needs
- Harden at edge: TLS 1.3, mTLS to origin, WAF rules, rate limiting and bot mitigation
- Instrument metrics (cache hit ratio, p50/p95/p99 latency), sample logs, enable tracing and alerts
Example use cases
- Global API acceleration using Cloudflare Workers with KV caching and wrangler.toml deployment
- Multi-tier CDN for a media site: edge PoP cache, regional edge for dynamic segments, origin shield to protect origin
- IoT gateway deployment using Azure IoT Edge containers for local orchestration and periodic cloud sync
- A/B testing and personalization via viewer_request edge functions with cache partitioning by segment
- Hybrid pattern: Lambda@Edge for CloudFront-integrated rewrites and Azure backend for private networking
FAQ
Choose Cloudflare Workers for global reach and minimal cold starts; use Lambda@Edge if tight CloudFront integration is required and you need the AWS event model.
How should I handle state at the edge?
Prefer stateless or KV caches for most cases; use CRDTs or event sourcing only when distributed state with eventual consistency is necessary and operational complexity is acceptable.