3 Software design patterns that every software data engineering should know
3 Software design patterns that every software data engineering should know
By Ana Escobar, DSTI School of Engineering (Ana Escobar is a Data enthusiast, passionate about Event-Streaming platforms | Data Platform Engineer at Lighthouse (formerly OTA Insight)

“A software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design.”
From the seminal book Design Patterns: Elements of Reusable Object-Oriented Software, 23 patterns are grouped into three categories: Creational, Structural, and Behavioural. Think of them as time-tested blueprints ,flexible templates for solving recurring problems in software architecture.
The 3 patterns covered
| #1 Singleton Guarantees a class has exactly one instance; ideal for shared resources like config managers or car-sharing apps. | #2 Factory Creates objects without specifying their exact class, great for generating diverse documents or reports. | #3 Observer One-to-many dependency, when one object changes, all dependents are notified. The backbone of push notifications. |
The 3 Design Patterns Every Developer Should Know
If you’ve been writing code for a while, you’ve almost certainly run into the same problems over and over — how to manage shared state, how to instantiate objects cleanly, how to keep loosely-coupled components in sync. Design patterns exist precisely to solve these recurring headaches.
In a recent article on Medium, the author draws from the classic book Design Patterns: Elements of Reusable Object-Oriented Software to highlight three patterns that every developer, and especially Data Engineers, should have in their toolkit.
The first is the Singleton pattern, a Creational pattern that ensures only one instance of a class ever exists. The author illustrates this with a car-sharing app where you absolutely cannot have two users editing the same car object simultaneously.
The second is the Factory pattern, also Creational, which lets you create objects without hardcoding their exact class. It’s particularly elegant when you need to generate many similar but different outputs, think different report formats in a document management system.
The third is the Observer pattern, a Behavioural pattern that powers the publish-subscribe model behind the notifications on your phone. One subject, many listeners, all updated automatically when state changes.
Beyond the explanations, the author backs each pattern with real-world analogies and even links to personal GitHub projects where the patterns were applied in practice.
Curious to see the code examples and diagrams? Read the full article on Medium.
Comments0
Please log in to see or add a comment
Suggested Articles