Author Archives: Allen Rodriguez
Fabric data pipelines become important when data engineering stops being a sequence of successful demos and becomes a repeatable production lifecycle. For DP-700, orchestration is not just arranging activities on a canvas. It is deciding what is versioned, what can be retried, how parameters move between steps, who can promote changes, and how operators know […]
Spark notebooks are attractive because they combine code, narrative, interactive exploration, and distributed execution in one Fabric item. For DP-700, however, the important question is not whether a notebook can transform data. It is when a notebook is the right production artifact compared with a pipeline, Dataflow Gen2, SQL, KQL, or a Spark job definition. […]
Medallion architecture is simple on a whiteboard: bronze holds raw data, silver improves quality and structure, and gold presents curated data for analytics. In Microsoft Fabric, the pattern becomes useful only when engineers decide what each layer is allowed to change, how data moves between layers, and how failures are recovered. Those decisions are directly […]
A Fabric lakehouse is easy to describe as a combination of data-lake flexibility and warehouse-style table access. The architecture becomes more interesting when real constraints appear: multiple source systems, schema changes, late-arriving records, competing consumers, security boundaries, and the need to recover transformations without rebuilding the entire environment. Those are the conditions that make lakehouse […]
Microsoft Fabric is easiest to understand when it is treated as an engineering system rather than a menu of workloads. OneLake provides the shared data layer; Data Factory handles batch orchestration and movement; Real-Time Intelligence handles event-driven ingestion and analytics; Warehouse and Lakehouse expose different execution models; and governance spans workspaces, domains, item permissions, OneLake […]
AWS Backup can centralize policies and recovery points across many AWS resources, but successful backup architecture is not measured by the number of green backup jobs. For SAA-C03 design work, the meaningful question is whether the organization can restore the right data, into the right environment, within the required time, after the failure that actually […]
Multi-Region disaster recovery is not achieved by drawing the same application twice on an AWS diagram. For SAA-C03 architecture, a second Region is useful only if the organization knows what state is replicated, how far behind it may be, how traffic moves, which dependencies remain regional, and who has authority to declare and reverse a […]
Amazon CloudFront is often introduced as a content delivery network, but that definition is too shallow for architecture work. In an SAA-C03 design, CloudFront changes where requests terminate, how often origins are contacted, what data is cached, and which request attributes become part of the cache key. It can improve performance and reduce origin load, […]
Amazon Route 53 routing policies are easiest to understand when DNS is treated as a decision layer rather than as a traffic proxy. For SAA-C03 architecture work, the important question is what information Route 53 can use when answering a DNS query and what the client will do with that answer afterward. The service can […]
Distributed systems become easier to reason about when messaging is treated as an architectural contract rather than as a menu of AWS services. In the SAA-C03 context, the useful question is not whether Amazon SQS, Amazon SNS, or Amazon EventBridge can move a message. All three can participate in event-driven designs. The harder question is […]
Event-driven architecture diagrams are appealing because every box appears independent. A producer emits an event, a queue or bus carries it, Lambda runs some code, and another service receives the result. The difficult parts are hidden between the arrows: duplicate delivery, retries, backpressure, ordering, poison messages, concurrency, partial failure, schema changes, and the question of […]
DynamoDB performance problems are often blamed on “not enough capacity” when the real issue is how requests are distributed. A table can have plenty of aggregate throughput and still throttle a hot partition. Conversely, a team can overprovision read and write capacity while inefficient access patterns consume far more units than the application actually needs. […]
Aurora is easy to describe as a managed relational database compatible with MySQL or PostgreSQL. That description is accurate but architecturally incomplete. The useful distinction is that Aurora separates compute instances from a distributed cluster volume. The writer and readers connect to the same logical storage system, while the storage layer replicates data across Availability […]
“Use Multi-AZ for availability and read replicas for scale” is a useful starting sentence, but it has become too simple for the current RDS landscape. A traditional Multi-AZ DB instance deployment has a standby that exists for failover and does not serve application reads. A Multi-AZ DB cluster, by contrast, has a writer and two […]
EBS, EFS, and EC2 instance store can all appear next to an EC2 workload, but they represent different persistence and sharing models. Choosing among them by price per gigabyte or a single performance number misses the design boundary. The important questions are whether data must survive instance replacement, whether multiple hosts need concurrent access, which […]
